search

w3f / bls

Aggregatable BLS sigantures
65 stars 15 forks source link

Adopt the IRTF CFRG draft standard #5

Open burdges opened 5 years ago

burdges commented 5 years ago

There is a new hash to curve function implemented in the fork https://github.com/kwantam/pairing/ via https://github.com/zkcrypto/pairing/issues/56#issuecomment-501928322 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 https://github.com/zkcrypto/pairing/pull/30 but Wahby-Boneh sounds interesting too.

burdges commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Depends on what you mean by silly :smile:

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 commented 5 years ago

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