Why would the use of Curve25519 in Dragonfly leak information?

Question

An answer explaining Dragonfly, a form of key exchange used in WPA3, has an interesting footnote:

One final note: reviewing the Firefly RFC, I see that it would (as written) leak some information if you run in on an elliptic curve that doesn't have a prime number of points (that is, has a cofactor $h \gt 1$). If you're using (say) the NIST curves, that's not an issue; if you try to adapt it to run over (say) Curve25519, that would need to be addressed...

Why is this, and what would be leaked if using a curve without a prime number of points?

Answer 1

In the Dragonfly protocol on an elliptic curve, the password is mapped to a point $P$, and then both sides exchange (among other things) the values $-mP, -m'P$.

If the elliptic curve has a composite order, and in particular, has a small cofactor $h$, then it is easy, given a value $P = xG$ (where $G$ is a generator), to find the value $m \pmod h$, that is, the order (mod $h$) of $P$.

So, if an attacker observes an exchange between two legitimate parties, what he can do to test a potential password is to map it into a point $P'$, and compute the order (mod $h$) of $P'$, and the two observed values $-mP, -m'P$. If his guess of the password was correct, then the order of $-mP, -m'P$ will always be a multiple of $P'$; if it is not, his guess of the password is impossible, and so he can remove that from his list.

Using this logic, it is likely that the attacker ma be able to eliminate approximately half of his dictionary entries by listening into one (or possibly several in a slightly more sophisticated version of this attack); this is contrary to the security goals of Dragonfly.

Also, it would be fairly easy to modify the HuntAndPeck procedure to avoid this weakness (just multiply the derived point by $h$); however the RFC doesn't specify that...