I've been looking into implementing cPace, and I saw that two cipher suites defined for it refered to draft-irtf-cfrg-hash-to-curve for its protocol definition. Part of cPace requires mapping a string hash to a point on the elliptic curve, so it uses the other standard's methods for doing that, in particular its choice of
map_to_curve for each curve.
Looking through draft-irtf-cfrg-hash-to-curve, its provided options for
map_to_curve, such as Simplified SWU and Elligator 2, seem rather complicated to me. It seems to me that, for example, Elligator 2 is performing a lot of steps to be able to perform this mapping. There is also the issues of (some implementations of)
map_to_curve that require additional steps, such as summing two calls to
map_to_curve to even the distribution and having to remove the cofactor from the result.
It seems to me that it should be simple enough to map an integer/field element $u$ to a curve point by just using $uG$ with $G$ being the generator for the curve. I can't figure out why this method wasn't used instead. Through my research into Elligator 2, I found that it was originally designed to be a two-way mapping, but the (draft) specification is using it in a one-way context.
What is (or might be) the reason why algorithms like Elligator 2 are being used for this instead of just using $uG$? My best guess so far is for efficiency because Elligator 2 is faster than computing $uG$, but I haven't found any evidence that was the consideration, and I don't know if it even is faster.
As a follow-up question, would it be wrong to replace Elligator 2 with $uG$? I.E. would it result in making the protocol cryptographically weaker? I was looking to implement cPace, but the library I'm using (OpenSSL) doesn't provide an implementation of Elligator 2 nor provide an interface for working directly with curve points on X25519 to help with my own implementation, but it does provide access to performing $uG$ as part of its DH implementation.