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

BLS Hash to G2 #898

Closed
kirk-baird opened this issue Apr 12, 2019 · 5 comments · Fixed by #1103
Closed

BLS Hash to G2 #898

kirk-baird opened this issue Apr 12, 2019 · 5 comments · Fixed by #1103
Labels
general:bug Something isn't working

Comments

@kirk-baird
Copy link
Contributor

Issues

The hash and test method used for mapping a message to G2 point is not incremented correctly.

def hash_to_G2(message_hash: Bytes32, domain: uint64)

How it currently behaves

Currently the function hashes to an x value then increments this x-value until a valid curve point is found.

How it should behave

In the case where the initial hash(m) does not generate a valid curve point:

The message is modify either by:
a) Incrementing the appended \x01 and \x02 bytes for each failed attempt
b) Modifying the message in some other incremental way

Hash this new set of bytes and check if it is a valid curve point.

Modify the message again and repeat this process until a valid point is discovered

Additional Info

It may be worth waiting for clarification from the standardization process before deciding how to modify the original message.

@JustinDrake
Copy link
Contributor

Judging from today's BLS standardisation call, it sounds like the constant-time Fouque-Tibouchi method may be preferable to hash and increment.

@JustinDrake JustinDrake added the general:bug Something isn't working label Apr 12, 2019
@djrtwo
Copy link
Contributor

djrtwo commented Apr 17, 2019

My gut is to leave this bug until we have the standard we all intend to conform on (probably Fouque-Tibouchi) to prevent everyone from opening up their bls implementations.

That said, my gut could be wrong as it is knowingly leaving insecure crypto sitting around. Any other opinions?

@hwwhww
Copy link
Contributor

hwwhww commented May 7, 2019

Per @JustinDrake's comment #1000 (comment)

BLS standardisation is unlikely to be finalised by June 30, although significant progress will have been made. Any inconsistency with the final BLS standard will have to be reflected in the launch release.

Do you think this bugfix should be delayed/removed from June 30 Frozen milestone?

@JustinDrake JustinDrake removed this from the Phase 0 Frozen milestone May 7, 2019
@JustinDrake
Copy link
Contributor

I agree with Danny, i.e. "leave this bug until we have the standard". The latest standardisation direction is to move to the new Wahby-Boneh hash function. https://eprint.iacr.org/2019/403

Removed from Phase 0 Frozen milestone, and suggest closing.

@djrtwo
Copy link
Contributor

djrtwo commented May 8, 2019

I don't suggest closing a known bug issue unless it is either fixed or a warning is added to the spec itself

JustinDrake added a commit that referenced this issue May 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general:bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants