To get H we hash G using keccak, interpret the result as a compressed Ed25519 point, then multiply by 8 to ensure the point is in the subgroup of the base point G.

  • How can we be sure there is no bias in generating this point from the hash function?

  • If there was a flaw in keccak, could this introduce a bias in the generation of H?

  • 2
    We rely on keccak being unbiased, and the ECDLP being hard. Perhaps there are some patterns in the distribution of mappings between 256-bit integers and EC points, which is why we did something as straightforward as having G hashed directly, so that we can claim "nothing up my sleeve". You might want to post this question on crypto.stackexchange.com where there might be much cleverer answers about whether there are any patterns in mappings between integers and curve points.
    – knaccc
    Jun 4, 2019 at 14:40

1 Answer 1


This question seems to boil down to whether Keccak is suitable for the random oracle model.

This answer on crypto.stackexchange.com should answer your question: https://crypto.stackexchange.com/q/70707/69644

As far as I know, there is no bias when going from the low order group to the prime subgroup.

Sidenote: there was an unrelated attack related to the key image in one of the first papers on ring sig, due to the way that the hashing was completed.

$ I = xH(P) $

Where $P = xG$

Defining the hashing function H as $keccak(data) * G$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.