Die Additionsformeln für Weierstraß-Kurven verwenden den Koeffizienten b nicht, deshalb berechnet Code, der die Kurvengleichung nie prüft, bereitwillig d·P für einen Punkt P auf einer anderen Kurve mit kleiner Untergruppe. Jede Antwort (ein gemeinsames Geheimnis aus ECDH, eine verschlüsselte Nachricht, ein MAC) verrät d modulo einer kleinen Primzahl, und der chinesische Restsatz setzt genügend davon zum vollständigen Schlüssel zusammen. Biehl, Meyer und Müller beschrieben den Angriff 2000; Jager, Schwenk und Somorovsky führten ihn 2015 gegen TLS-ECDH-Implementierungen vor, und 2017 stellte sich heraus, dass mehrere JOSE-Bibliotheken ungültige Punkte in ECDH-ES akzeptierten.
Die Abhilfe kostet wenig: Prüfe, dass der Punkt auf der Kurve liegt, nicht der Punkt im Unendlichen ist und, wenn der Kofaktor größer als 1 ist, in der richtigen Untergruppe liegt (SEC 1 §3.2.2, SP 800-56A §5.6.2.3). Die meisten modernen Bibliotheken validieren beim Import. X25519 und X448 sind so konstruiert, dass die Montgomery-Leiter auch auf dem Twist sicher bleibt; übrig bleibt nur die Prüfung, ob die Ausgabe nur aus Nullen besteht.
Ein verwandter Fehler ist, Kurvenparametern zu vertrauen, die der Aufrufer liefert: Bei CVE-2020-0601 („CurveBall“) akzeptierte die Windows CryptoAPI Zertifikate, deren explizite Parameter einen vom Angreifer gewählten Generator einsetzten, sodass sich ein gefälschtes Zertifikat als vertrauenswürdiges Root-Zertifikat ausgeben konnte. Nur benannte Kurven (Named Curves) zuzulassen, wie es RFC 5480 verlangt, schließt diese Lücke.