Assessment reports>Session Token>Low findings>Bias in ,hashToField, function
Category: Coding Mistakes

Bias in hashToField function

Low Severity
Low Impact
Low Likelihood

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.

Zellic © 2024Back to top ↑