search

fcelda / nsec5-draft

Working Copy of the NSEC5 Specification
15 stars 2 forks source link

do we want to keep xC2xyC in VRF draft? #23

Closed goldbe closed 7 years ago

goldbe commented 7 years ago

To deal with different ways of encoding compressed curve points for 25519 and p256, I introduced the function xC2xyC that converts (the octet representation) of an x-coordinate of an EC point to (the octet representation) of a compressed EC point. This function will be different for 25519, p256, and ed448.

The upside: This way we keep ECVRF_hash_to_curve1() modular and working for all 3 curves, and we just need to specify xC2xyC as part of the ciphersuite.

Downside: This is a funny looking function that I just made up. Is there a more standard way to deal with this?

All of these changes are in https://github.com/fcelda/nsec5-draft/commit/a44dcb4b36ad31f3753166a0008028f55f4e1fc9

goldbe commented 7 years ago

Leo make me get rid of xC2xyC. Now we have RS2ECP instead.

https://github.com/fcelda/nsec5-draft/commit/b3ec8ba7f3e59976febbfcb283aa1f6df3e4ae0a

goldbe commented 7 years ago

But, can others please have a look at RS2ECP and let us know if they like it. I'm pretty happy with this change.

fcelda commented 7 years ago

Reviewed. Looks good. I will send pull request with some minor change proposal.