Montgomery Elligator Support and Random Point Generation on Edwards Curve #326
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With an intention of having hash-to-curve methods which are applicable to
EdwardsPoint
, I wrote elligator support for Montgomery curve and using that, added methods likeEdwardsPoint::hash_from_bytes
,EdwardsPoint::from_uniform_bytes
,EdwardsPoint::random
for Edwards curve.Note that in the last step of
from_uniform_bytes
, I multiply the resultingEdwardsPoint
with scalarScalar::from(8u8)
in order to make sure it lies in the prime order subgroup. Although this is exactly why Ristretto must be used to avoid such modifications which might result into vulnerabilities, but for existing systems which use Edwards' prime order subgroup, support for such functions becomes necessary. If someone wants to write a protocol for say Monero (Edwards curve) and leverage the multi-scalar multiplication and other features ofcurve25519-dalek
, support of such functions forEdwardsPoint
s becomes crucial.An issue was raised by @omershlo in the past for the same. #188