Maybe add a page for Hash to curve?

[LoupVaillant]

Why we might want to add that page:

• Elligator's original use case notwithstanding, it seems most of the effort goes to map-to-curve and hash-to-curve. See Libsodium, Dalek, and the RFC draft.
• Map-to-curve and hash-to-curve do more than just apply the direct map, we might want to explain what goes there.

Why we might want to hold our horses:

• The relevant RFC is still a draft.

[fscoto]

The draft is pretty mature at this point and probably also the largest point of friction because a bunch of IETF protocols will pull it in (e.g. ECVRF in I-D.draft-irtf-cfrg-vrf). Addressing it seems almost imperative.

[LoupVaillant]

Fixed now. We may need to flesh it out in the future (Curve448, Ristretto, full RFC compliance…), but I think explaining the general concepts and giving one concrete example would be best.

Right now I based this entirely on libsodium, for two reasons:

• The RFC is so generic it becomes almost unreadable. I tried, but it was just too much effort.
• Libsodium is there, it works, and it has established a norm that as far as I can tell has established a precedent other libraries (Dalek) follow.

To be checked, but I believe what libsodium does not comply with the hash_to_field() step of the RFC (though it does have an alternative). I think we don't really care here because p is close enough to a power of two that we don't need to take any special precaution.