Bias in hashToField
function
Description
The function hashToField
is used to hash a uint256
value to . The resulting value is later mapped to a point on an elliptic curve with the function mapToG2.
The message is first hashed with the keccak256
function and then transformed to a value in the finite field with the function maskBits
:
// This matches mcl maskN, this only takes the 254 bits for the field, if it is still greater than the field then take the 253 bits
function maskBits(uint256 input) internal pure returns (uint256) {
uint256 mask = ~uint256(0) - 0xC0;
if (byteSwap(input & mask) >= FIELD_MODULUS) {
mask = ~uint256(0) - 0xE0;
}
return input & mask;
}
The two first bits of the value are set to zero, and then if the value is still bigger than , the next bit is masked to zero. It means that the values between and are mapped to a value between and . Values between zero and are left unchanged, resulting in values in the range having twice the probability to be chosen as output.
Impact
In the original BLS paper, the author assumed a function seen as a random oracle, which is not the case with such a construction. It seems difficult to exploit such bias in practice; however, the BLS-signature security proof does not apply anymore with such construction.
Recommendations
The construction should output uniformly distributed values with negligible bias similarly to the hash_to_field
function defined in the RFC 9380↗.
Remediation
This issue has been acknowledged by Session team, and a fix was implemented in commit 58d5c68b↗.