If I have some bytes, and I want to compute a secure hash into a prime field which is 300 bits long I can:
Use a nice hash, like sha3_512, and then
modulo my prime field (introduces some bias).
toss bits most significant bits away until the number is < my prime (some bias toward smaller numbers)
toss bits most significant bits away until 300 bits, and then modulo my prime if needed (less bias?).
toss bits most significant bits away until 300 bits, then start over (hash the hash) if the number is too big (eventually converge). (no bias, slow)
???? some better method ????
How important is the bias overall?
If I'm using the resulting hash as the hash for a EC signature scheme, it's insignificant...since the hash isn't protecting anything... it's just collisions that are a concern, which we've made worse by a fraction of a bit.
If I'm using the resulting hash as a "nonce" to protect a secret value during, for example, an mpc computation, it could be "leaky". Over many uses of such a scheme someone might be use the bias to attack the key or the mpc. The same holds for deterministic nonces used to reduce signature malleability, which is why I think they are a very bad idea. See https://ecc2017.cs.ru.nl/slides/ecc2017-tibouchi.pdf, for just how bad this is.
If I'm using the resulting hash as the private part of an pairing based signature scheme (which requires mapping a message into the curve) , it seems to me that the bias just causes a similar collision loss.
Has anyone compared masking methods for bias? Is there a good reference on best practices? IS there a good analysis of the types of protocols for which such masking is a concern?