I know that the cofactor of curve 25519 is 8. Is it the maximum factor in the existing curve used for ECDSA?
-
1What is the reason behind this question? – kelalaka Mar 04 '21 at 16:06
-
just curiosity~ – user77340 Mar 05 '21 at 02:35
-
Similar https://crypto.stackexchange.com/questions/2881/why-would-anyone-use-an-elliptic-curve-with-a-cofactor- – dave_thompson_085 Mar 05 '21 at 03:21
1 Answers
The X9.62 ECDSA standard does not specify a bound on permissible cofactors (though it only records how to validate cofactors up to about $\sqrt p/4$). The Certicom SEC1 document only allows cofactors up to $2^{t/8}$ where $t$ is the bit size of the field. In theory then, quite large cofactors might be in use somewhere. In practice people almost always preferred to use Weierstrass curves with cofactor 1 a) for efficiency and b) to avoid possible weaknesses with unverified parameters. I believe that all of the NIST standard curves have cofactor 1 for example. By contrast Curve 25519 allows a cofactor so that it can have a compatible Edwards curve representation (Edwards curves are more efficient and have better anti-sidechannel properties; their order over prime fields is always divisible by 4 however). Similarly Curve 448 has a cofactor of 4 and an Edwards form.
ETA: kelalaka points out that 25519 pre-dates Edwards curves; it was a happy coincidence that it was Edwards compatible.
In pairing-friendly cryptography larger cofactors can be quite common as there are very stringent conditions on the curve order. Such curves are however not generally used for ECDSA.

- 23,716
- 1
- 29
- 67
-
-
Maybe we can call this as the Swan Song of the Harold Edward died last year :( – kelalaka Mar 04 '21 at 19:30
-
2X9/NIST/SECG $F_p$ curves (secp#r aka P-# random and secp#k Koblitz) have cofactor 1; the $F_{2^m}$ curves (sect#r aka B-# random and sect#p aka K-# Koblitz) which now are rarely used have 2 or 4. See SEC2 and FIPS186-2 or higher. Brainpool (only $F_p$) are also 1. – dave_thompson_085 Mar 05 '21 at 03:24