Adopt the IRTF CFRG draft standard

[burdges]

There is a new hash to curve function implemented in the fork https://github.com/kwantam/pairing/ via zkcrypto/pairing#56 (comment) which should be evaluated.

There is also a draft BLS standard by the IETF at https://datatracker.ietf.org/doc/draft-boneh-bls-signature/ but they only hash-to-G1, which makes verification slow after extensive aggregation. In fact, you'd only ever use BLS with extensive aggregation, so this sounds silly, but perhaps hash-to-G2 is so slow that more extensive aggregation is required before hash-to-G2 wins.

Also, the standard recommends hashing-to-G1 with try-and-increment, which sound archaic. We currently use Michael Orru's adaptation of Fouque-Tibouchi as implemented in zkcrypto/pairing#30 but Wahby-Boneh sounds interesting too.

[burdges]

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

[kwantam]

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.)

[burdges]

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.

[burdges]

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.

[kwantam]

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.

[burdges]

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