Truncate hash output rather than modulo p
#142
Description
I know @sanchopansa asked this question privately, and I remember responding at the time that I was unable to find bias in the outputs with a range of small primes (where a brute-force approach was possible)
Also referencing: Loopring/protocol3-circuits#7
The goal is to Identify where hash output is computed modulo N rather than truncated to a number of bits where it fits safely within the field. I would have thought that for modulo reduction vs truncation, if the source number is at 2 bits larger than the result, then you would get even uniformly random distribution, rather than the
The following reference is useful: https://ericlippert.com/2013/12/16/how-much-bias-is-introduced-by-the-remainder-technique/ - However, that is with a 2^n
extension field rather than a prime field.
The libff::Fp_model::random_element()
function sets the highest bits to zero until it's below the modulus, which is equivalent to masking the least significant FieldT::capacity()
bits.
Locations:
- https://github.com/HarryR/ethsnarks/blob/master/ethsnarks/eddsa.py#L147
- https://github.com/HarryR/ethsnarks/blob/master/src/jubjub/point.cpp#L78
- https://github.com/HarryR/ethsnarks/blob/master/ethsnarks/poseidon/permutation.py#L105
- https://github.com/HarryR/ethsnarks/blob/master/ethsnarks/mimc.py#L94
- https://github.com/HarryR/ethsnarks/blob/master/contracts/MiMC.sol#L63
- https://github.com/HarryR/ethsnarks/blob/master/ethsnarks/jubjub.py#L214
I can't find any other locations where something is interpreted as mod p
rather than truncating to floor(log2(p))
bits.
There is one location where the output of a hash is truncated: