Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HashToField does not follow RFC9380 depending on the curve modulus #849

Open
azixus opened this issue Jul 30, 2024 · 0 comments
Open

HashToField does not follow RFC9380 depending on the curve modulus #849

azixus opened this issue Jul 30, 2024 · 0 comments

Comments

@azixus
Copy link

azixus commented Jul 30, 2024

While implementing hash to curve for an unsupported curve, I've discovered a bug in the implementation of DefaultFieldHasher:

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).

See an example of the issue on secp256k1 at https://gist.github.com/azixus/2edc9485ecd386578aff0bd3f9a71b84

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant