search

cfrg / draft-irtf-cfrg-bls-signature

32 stars 16 forks source link

BLS v3 with hash-to-curve v7 #22

Closed CarlBeek closed 4 years ago

CarlBeek commented 4 years ago

Now that hash-to-curve v7 has been released, it would be greatly appreciated if we can update these specs with a new version to support the new H2C.

For Eth2.0 in particular, we are planning on shipping with BLS v2 and hash-to-curve v7, so it would be ideal if this could be enshrined as an official release to use as a Schelling point as the inter-blockchain standard.

kwantam commented 4 years ago

:+1: this will happen automatically with the next release.

hwwhww commented 4 years ago

@kwantam Since #26 is not backward compatible, by any chance, is it possible to have a release before #26?

kwantam commented 4 years ago

Can you help me understand the specific backwards compatibility concern? Is it the fact that SK = 0 is disallowed now (which is not a backwards compatibility issue for honest clients, because with overwhelming probability no honest client has SK = 0), or is it the change to the salt value used in KeyGen?

If it is the change to KeyGen, note that the document explicitly allows you to make minor tweaks to KeyGen, meaning that it would be fine to delay computing salt = H(salt) until the second iteration of the loop (equivalently, to move that line to the end of the loop body). The new version of KeyGen is slightly more conservative, but there is no known attack against the prior version.

kirk-baird commented 4 years ago

Can you help me understand the specific backwards compatibility concern? Is it the fact that SK = 0 is disallowed now (which is not a backwards compatibility issue for honest clients, because with overwhelming probability no honest client has SK = 0), or is it the change to the salt value used in KeyGen?

Yep, the backwards compatability is disallowing SK = 0. This could raise a consensus bug in Ethereum2.0 for if an adversary deliberately choose SK = 0 and signed a message. If some clients are using BLS v+3 and some are using BLS v2 some clients would reject the signature and other accept it. Thus, we would have a fork in the chain which is highly undesirable.

Although no honest actors would likely pick SK = 0 it would be trivial for malicious actors to create this situation.

KeyGen is fine for backwards compatability as all keys generated in v+3 (1 <= sk < r) would be accepted by v2 (0 <= sk < r).

hwwhww commented 4 years ago

Thank you for the reply @kwantam! As @kirk-baird answered, we care more about the KeyValidate change. It may result in a potential consensus error for the application that already accepted SK = 0 case.

Another meta reason for Eth2 BLS library implementation. Eth2 is using an awkward version BLSv2 + hash-to-curve draft v7. Afaik the BLS12-381 G1 and G2 ciphersuites of hash-to-curve draft v9 are compatible with the v7 version. So we'd appreciate it if there is a release of either:

  1. BLS draft v3 = pre-#26 + hash-to-curve draft v7 or
  2. BLS draft v3 = pre-#26 + hash-to-curve draft v9.

It will help us define the status-quo BLS implementation version formally and avoid the ambiguity between the current version and the post-#26 version.

kwantam commented 4 years ago

Done. Version -03 is pre-#26 + hash-to-curve-09.

I will now upload -04 :)

kwantam commented 4 years ago

Closing this issue. Feel free to reopen if you'd like to discuss further.

hwwhww commented 4 years ago

Thank you @kwantam!

Could you also upload -03 to IETF? I can only see -04 on https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-04, but no -03.

kwantam commented 4 years ago

Should be there. Sometimes it takes a while for tools to generate the HTMLized document.

https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-03

hwwhww commented 4 years ago

@kwantam I can see it now, thank you! :)