-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove SWUMap and WBMap, fix MapToCurve semantics #629
Comments
In principle, we could merge
Ain't so clear if this plays nicely with |
I think the orphan rules obstruct many approaches here, so #643 leaves these types and traits. |
Afaik, there is no reason for WB hash-to-curve when SWU hash-to-curve works, right? Also, There is only one suite listed for each curve in https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve-16#name-suites-for-hashing As an aside, they refer to both WB and SWU as SSWU.
There are reasons to expose the underlying map-to-curve as their hash-to-field favors expand_message_xmd for sha256 when other likely prefer expand_message_xof for blake2x, shake, merlin, etc. and even PRNGs
It seemingly follows we should remove the
SWUMap
andWBMap
types, replace theirMapToCurve
methods by free methods, likeand
We finally replace the
MapToCurve
trait byIndividual curves then
impl MapToCurve
by invokinghashing::swu::map_to_curve
orhashing::wb::map_to_curve
as appropriate.Afaik, we've no reason to output an affine point here like we currently do. In fact, we pointlessly normalize the point both before and after a cofactor multiplication right now.
The text was updated successfully, but these errors were encountered: