Skip to content
ecdsa.com

Invalid-curve attack

An attack in which a peer sends a point that is not on the agreed curve, so an implementation that skips point validation computes on a weaker curve and leaks its private key piece by piece.
Also written asinvalid curve attacktwist attackpoint validationCurveBall

Weierstrass addition formulas do not use the coefficient b, so code that never checks the curve equation will happily compute d·P for a point P on a different curve with a small subgroup. Each response (an ECDH shared secret, an encrypted message, a MAC) reveals d modulo a small prime, and the Chinese remainder theorem combines enough of them into the full key. Biehl, Meyer and Müller described it in 2000; Jager, Schwenk and Somorovsky demonstrated it against TLS-ECDH implementations in 2015, and in 2017 several JOSE libraries were found to accept invalid points in ECDH-ES.

The fix is cheap: check that the point is on the curve, is not the point at infinity and, when the cofactor exceeds 1, lies in the right subgroup (SEC 1 §3.2.2, SP 800-56A §5.6.2.3). Most modern libraries validate on import. X25519 and X448 are designed so that the Montgomery ladder stays safe on the twist, leaving only the all-zero output check.

A related failure is trusting caller-supplied curve parameters: Windows CryptoAPI's CVE-2020-0601 ("CurveBall") accepted certificates whose explicit parameters substituted an attacker-chosen generator, letting a forged certificate impersonate a trusted root. Named curves only, as RFC 5480 requires, close that door.

Standards and references

All terms