Cannot you move this under line 227 to increase performance? about relic HOT 10 CLOSED

Looks like it, even though it's just one field multiplication. :)

from relic.

Also, what about using y = g(x)^{(p+1)/4} instead of taking the square root for BLS12-381? Which approach is better?

from relic.

That's exactly what square root computes in case of the BLS12 prime (or any prime = 3 mod 4). :)

For faster hashing, there should be an update in a few weeks implementing https://eprint.iacr.org/2022/759, so stay tuned!

from relic.

I know that they're equivalent, I'm just wondering which one is more expensive to calculate. Thank you for the article, I'll have a look.

from relic.

Sorry if my comment was not clear. In RELIC, fp_srt() extracts the square root exactly by computing the exponentiation.

from relic.

Thanks. Now I see. I should have look at it myself though...

from relic.

There is one more thing I don't understand. In "Fast and simple constant-time hashing to the BLS12-381 elliptic curve" the second square root is avoided by calculating y as t^3*alpha, but in your implementation you calculate two square roots. Can you explain me the reason?

from relic.

We did not have a fast squaredness test at the time, but now we have a pretty good one (upcoming paper on CCS'23 -- built upon ideas from https://eprint.iacr.org/2021/1271).

There is quite a bit of movement happening in the hashing part, including a new function and an attempt to make this one faster/constant-time: 5bd2b8b

from relic.

Sounds good. I'll have a look at it. Thank you for clarifying.

from relic.

I just merged a large patch with many new hash-to-curve algorithms for the various cases. Some polish is still pending for automatic selection, but the basics are there.

from relic.