Adopt the IRTF CFRG draft standard about bls HOT 6 OPEN

Sorry to chase you around :) but just a quick note: the hash-to-curve impl is in https://github.com/kwantam/bls_sigs_ref/. (My fork of the pairing crate just adds a feature that (effectively) exposes the constructors for the low-level point representations.)

from bls.

Ideally we should increase the compliance with the IRTF CFRG drafts for BLS signatures and hash-to-curve throughout, without doing anything silly like using SHA2-HMACs everywhere.

from bls.

Depends on what you mean by silly 😄

At the least it's sensible to try and make sure that whatever hash function to the base field you decide to use has an indifferentiability proof in some reasonable model. Hash-to-curve is adding (very barebones) support for defining alternative hash-to-base functions in the next draft. KMAC and cSHAKE both look like they'd work if you want to use a SHA-3--ish function, and Blake2X-on-Blake2b also looks like it could work.

I'm happy to give feedback on whatever you land on.

edit:

more flexibility than the standard, like permitting signatures on either group.

I'm sure you know this by now, but the most recent version of the BLS document supports signatures on both groups.

from bls.

Appears the IETF working draft is https://github.com/pairingwg/bls_standard/blob/master/minutes/spec-v1.md not the version on the webpage.

from bls.

I'm interested in aligning with https://github.com/kwantam/bls_sigs_ref as much as possible, although I obviously want to provide more flexibility than the standard, like permitting signatures on either group. See also https://github.com/algorand/bls_sigs_ref

I suppose the hashing functionality could be relegated to some trait that supported both STROBE and conventional hash functions, as BLS has no need for the superior domain separation of STROBE.

from bls.

Thanks! I'll attempt to catch back up on this eventually, but not anytime this month I fear.

from bls.