Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.
The specific security and behaviour of an ECC scheme depends entirely on the curve chosen. The most widely deployed curves are: P-256 (also called secp256r1 or prime256v1, an NIST/FIPS-standardised curve, the default in most TLS deployments and X.509 certificates), P-384 (NIST curve, required by NSA CNSA 1.0 for top-secret data, slower than P-256 with more conservative security margin), P-521 (NIST curve, highest classical security, rarely deployed), X25519 (Bernstein’s Curve25519 used for Diffie-Hellman key exchange, designed for safety and performance with a simple constant-time implementation, default in TLS 1.3 key exchange and WireGuard), and Ed25519 (Edwards-form Curve25519 used for EdDSA signatures, the default SSH host key and user key algorithm since OpenSSH 6.5, notably faster and simpler to implement safely than ECDSA). The NIST P-curves carry a lingering concern among cryptographers about the verifiability of their parameter generation (“nothing up my sleeve” questions about seed values), whereas Curve25519/Ed25519 have fully transparent, verifiable parameter generation — an important consideration for high-assurance deployments.
Like RSA, all ECC algorithms — ECDH, ECDSA, EdDSA — are broken by Shor’s algorithm on a CRQC. The ECDLP is no harder than integer factorisation against a quantum adversary; Shor’s algorithm solves both in polynomial time. NIST IR 8547 designates all ECC-based algorithms for deprecation in new systems after 2030 and disallowance after 2035. The HNDL threat is particularly relevant for ECDH key exchange in TLS sessions recorded today: although TLS 1.3 provides forward secrecy (ephemeral ECDHE), the session key is only as quantum-safe as the key exchange algorithm, and ECDHE is not. The migration path replaces X25519/ECDHE with ML-KEM for key encapsulation (currently deployed in hybrid X25519MLKEM768 form in TLS 1.3) and ECDSA/EdDSA with ML-DSA for signatures. The hybrid transition period, where both an ECC share and an ML-KEM share are combined in the key exchange so the session is secure against both classical and quantum attackers simultaneously, is the standard recommended by NIST and already deployed by default in Chrome 131+ and available in OpenSSL 3.4+.