Eth2.0-specs: BLS Hash to G2

Created on 12 Apr 2019  路  5Comments  路  Source: ethereum/eth2.0-specs

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.

bug

Most helpful comment

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?

All 5 comments

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

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?

Per @JustinDrake's comment https://github.com/ethereum/eth2.0-specs/issues/1000#issuecomment-489433518

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?

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.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JustinDrake picture JustinDrake  路  15Comments

JustinDrake picture JustinDrake  路  12Comments

hwwhww picture hwwhww  路  13Comments

paulhauner picture paulhauner  路  12Comments

spble picture spble  路  26Comments