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

Support BN curves in the BLS aggregate signature #218

Closed
chancharles92 opened this issue Mar 28, 2023 · 3 comments · Fixed by #223
Closed

Support BN curves in the BLS aggregate signature #218

chancharles92 opened this issue Mar 28, 2023 · 3 comments · Fixed by #223
Assignees

Comments

@chancharles92
Copy link
Contributor

chancharles92 commented Mar 28, 2023

BLS signature on ethereum (uses BN256 curve)

cc @philippecamacho @mrain

@philippecamacho
Copy link
Contributor

philippecamacho commented Mar 31, 2023

Update regarding hashing to curve.

Context

We need to implement a hash to curve algorithm for the pairing friendly curve currently supported by Ethereum which is Bn254. We can either implement the naive method sometimes called "hash and pray" that consists of taking a field element $x$ , plugging it into the elliptic curve equation and hoping it is a quadratic residue. If not we try with $x+1$, if this fails again we try with $x+2$ and so on and so forth. This method takes only a few iterations as the probability of failure for k attempts heuristically is $2^{-k}$. A problem of this approach is that the time to compute the hash value is not constant which may leak information about the input or allow for some DoS attack if the hash function is computed inside a smart contract and an attacker is able to find an input $x$ so that $k$ is large.

Constant time hashing functions

Other hashing methods that are constant time exist though.

This seems a lot of work and implementing the hash to curve in solidity will be quite hard as well.

Decision

I think the hash and pray method is fine for now, as the hashed message is public and DoS attacks do not seem a concern. We can switch to a better (constant time) hash to curve algorithm later.

Later we may even use EIP-3068 directly that implements the Fouque-Tibouchi algorithm.

cc @chancharles92 @sveitser

@sveitser
Copy link
Contributor

Sounds reasonable. I'm okay with #️⃣ and 🙏.

@alxiong
Copy link
Contributor

alxiong commented Nov 27, 2023

I wonder if we don't need to do hash to curve inside the contract, (due to the special constraint that everybody sign the same message in our context), then would it affect our decision on which HashToCurve algorithm to implement?

On the task #373 , I'm thinking maybe I should simply go with Fouque-Tibouchi (or adapted WB)?

cc @philippecamacho @chancharles92 WDYT?

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

Successfully merging a pull request may close this issue.

5 participants