Hash to Curve

[spaceships]

Implement hash-to-curve as given in this spec

• Question: what is the public key Y for us? Do we ignore it? @iquerejeta
• Mod by q after hashing
• Implement it

[markulf]

What is special about

draft-irtf-cfrg-vrf-09?

Here is another hash to curve standard that does not have a public key Y as it is not for VRFs:

draft-irtf-cfrg-hash-to-curve-10.

Maybe add a warning about side channel vulnerability of try-and-increment. Not an issue in our case as the hashed value is not a secret.

[abakst]

@markulf if I understand it correctly, the latter document describes suites for specific curves, whereas the former includes a try-and-increment approach. Since we haven't settled on a particular curve, sticking with a rejection-based approach seems appropriate for now, (though there is still that question of the public key).

[abakst]

I believe the source of the try-and-increment algorithm is "Short Signatures from the Weil Pairing" (Boneh et al, 2001), which outlines the algorithm presented in this version of the above document (apparently removed from future versions due to the side channel vulnerability).

I think this is a reasonable specification to use for the initial Mithril implementation (until later when a curve-specific implementation can be used).

[abakst]

#15 was merged, so I suppose we can consider this closed.

[iquerejeta]

@abakst , indeed. We do not need to follow a hash-to-curve specification from the standard, as they only include constant time options, and try-and-increment is not constant time. However, as you stated, it is reasonable (and preferred) for now, to use try-and-increment until we close down on the curve.

The reason I shared the VRF standard is because we also use VRFs within Cardano, and make use of that specific instantiation. However, the instantiation in version 3 of hash-to-curve is ok 👍