Elliptic-curve cryptography

Elliptic-curve cryptography derives its security from arithmetic on points of an elliptic curve over a finite field. A curve is commonly written as y² = x³ + ax + b, with a discriminant chosen to avoid singularities; its points, together with a point at infinity, form an abelian group. Scalar multiplication repeatedly adds a point to itself, while reversing that operation—recovering a scalar from two points—is the elliptic-curve discrete logarithm problem.²

A private key is a randomly selected scalar, and the public key is the corresponding scalar multiple of a prescribed base point. The same structure supports both key-establishment protocols and signature systems, but a curve and encoding suitable for one protocol should not automatically be reused for another. Implementations normally operate over a prime field or a binary field, with modern standards favoring carefully specified prime-field curves.

ECC appears in distinct cryptographic roles rather than as one single algorithm. Elliptic-curve Diffie–Hellman derives a shared secret from two private keys; elliptic-curve digital-signature schemes authenticate messages; and hybrid encryption systems can use an elliptic-curve exchange to establish a symmetric session key. TLS 1.3 permits several elliptic-curve groups, including X25519 and X448, for key exchange.³⁵

EdDSA is a deterministic signature family built around Edwards curves, with Ed25519 and Ed448 specified for interoperable use.⁴ NIST standards also define approved curves and algorithms, including ECDSA and elliptic-curve key agreement, while distinguishing domain parameters, key-generation procedures, validation, and protocol-specific encoding.¹ These details matter: two systems can both claim ECC support while remaining incompatible.

ECC achieves strong security with shorter keys than classical finite-field or integer-factorization systems, reducing bandwidth, certificate size, and some computational costs. NIST’s security-strength guidance places a 256-bit elliptic-curve key in the approximate 128-bit security category, although the exact strength depends on the curve, algorithm, and attack model.

Correct implementation is as important as the underlying mathematics. Private keys require high-quality randomness; public points may require validation; signature nonces must never repeat or become predictable; and secret-dependent calculations should resist timing, cache, fault, and power-analysis attacks. Invalid-curve and small-subgroup attacks exploit failures in these checks rather than a break of the discrete-logarithm assumption. Standards such as RFC 7748 deliberately specify complete, interoperable procedures for modern Montgomery-curve operations, including input handling and serialization.³

ECC’s practical history includes a major shift from many independently chosen curves toward rigid, protocol-specific designs. Curve25519 was introduced for efficient Diffie–Hellman key exchange, while its related Edwards-curve constructions support Ed25519 signatures; the two families share mathematical relationships but are not interchangeable encodings or protocols.³⁴

Some less visible choices have large consequences. Cofactor handling affects subgroup security, compressed points trade computation for smaller representations, and deterministic signatures can reduce dependence on runtime randomness while still requiring protection of the private key. ECC is also not considered resistant to a sufficiently capable quantum computer: Shor’s algorithm would threaten its underlying discrete-logarithm problem. Consequently, standards bodies are developing and recommending post-quantum cryptography, while hybrid deployments may combine ECC with quantum-resistant mechanisms during migration.⁶

Elliptic-curve discrete logarithm problem

The problem of recovering a scalar k from points P and kP on an elliptic curve; its presumed computational difficulty underpins ECC.

ECDSA

Elliptic Curve Digital Signature Algorithm, a standardized public-key signature scheme.

X25519

A Diffie–Hellman key-agreement function using Curve25519-style Montgomery arithmetic.

Ed25519

A specific EdDSA signature scheme using a twisted Edwards curve and 255-bit field arithmetic.