You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
let len_per_base_elem = get_len_per_elem::<F,SEC_PARAM>();
let expander = ExpanderXmd{
hasher:PhantomData,
dst: dst.to_vec(),
block_size: len_per_base_elem,
};
When ExpanderXmd is initialized, len_per_base_elem is passed as the block size of the underlying hash function. It works seamlessly for curves with 381 bit modulus, because len_per_base_elem = ceil((MODULUS + 128)/8) == 64 which is the block size of SHA256. Since the block size is a parameter used in expand_message_xmd, the current implementation cannot pass test vectors when the above condition is false (e.g. 256 bits modulus).
The digest crate provides a block_size() function through the OutputSizeUser trait. I wrote a fix that further restricts the generic parameter to that trait here
I'll happily raise a PR if that change seems acceptable.
The text was updated successfully, but these errors were encountered:
While implementing hash to curve for an unsupported curve, I've discovered a bug in the implementation of
DefaultFieldHasher
:algebra/ff/src/fields/field_hashers/mod.rs
Lines 52 to 58 in dcf73a5
When
ExpanderXmd
is initialized,len_per_base_elem
is passed as the block size of the underlying hash function. It works seamlessly for curves with 381 bit modulus, becauselen_per_base_elem = ceil((MODULUS + 128)/8) == 64
which is the block size of SHA256. Since the block size is a parameter used inexpand_message_xmd
, the current implementation cannot pass test vectors when the above condition is false (e.g. 256 bits modulus).See an example of the issue on secp256k1 at https://gist.github.com/azixus/2edc9485ecd386578aff0bd3f9a71b84
The digest crate provides a
block_size()
function through theOutputSizeUser
trait. I wrote a fix that further restricts the generic parameter to that trait hereI'll happily raise a PR if that change seems acceptable.
The text was updated successfully, but these errors were encountered: