-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hashing to G1/G2/Fr/Fq/Fq2 #56
Comments
Any news on the hashing function? If they exist pairing can also be used for BLS signatures and multisignatures. Not just for zk-SNARKS based applications. |
I agree, that would be really helpful. |
If there's any interest, I have a Rust implementation of our work on fast hashing to BLS12-381 (WB19) based on (a slightly modified version of) this crate and following the draft BLS signatures standard. The hash functionality currently lives in its own crate (see the |
Is the IETF draft meant to propose the hashing-to-the-curve from the Wahby-Boneh? It reads like it specifies nothing but try-and-increment? In any case, the IETF draft covers only hashing-to-G1, which sounds insufficient anytime you actually want BLS signatures, but presumably your implementation fixes this? Or maybe the hashing-to-G2 is far slower than I realize? A priori, I'd think any general purpose BLS signature implementation should be generic over the curve roles, like https://github.com/w3f/bls/blob/master/src/lib.rs#L164 In that crate, I also concluded a BLS signature scheme should either handle only 32 bytes messages internally, or else unpack Blake2b to operate on raw ChaCha states, so that verification algorithms could operate more efficiently https://github.com/w3f/bls/blob/master/src/verifiers.rs#L72 That'd simplify the spec slightly but make efficient implementations harder. If I understand, the concern about the Fouque-Tibouchi as implemented in #30 boils down to hashing not being constant-time, which I suppose never matters in BLS signatures. Or are there more concerns like performance there? |
I think the latest published version on the IETF page is badly out of date at this point. The latest working version is here. It covers hashing to both G1 and G2---both will be specified as separate ciphersuites. And I think it's safe to say that try-and-increment is out of the picture at this point. There are two related concerns about FT12:
In contrast, WB19 is constant time essentially for free (though, as you say, this doesn't matter that much for BLS signatures in particular), it costs exactly one exponentiation (which is inescapable, since one must compute a square root mod p), and fast implementations only need field arithmetic. That said, I don't speak for the standards folks, but my guess is that some variant of Shallue--van de Woestijne 2006 (either FT12 or something very close) will also be specified for certain ciphersuites. |
Hello there! I'm happy to see that the hashing issue has been taken back into consideration! I just wanted to remind you guys that in #30 I had a pull request exactly on this, and in #102 I had a fast cofactor multiplication implementation; in the Algorand implementation I'm not sure what's the purpose of having Plus I'm sketching Budroni-Pintore for clearing the cofactor in the RFC draft, which is much more concise than what's currently in Algorand, and it'd be nice to work on another implementation to have concrete benchmarks. EDIT: I slightly changed the tone in a previous sentence, which reading back didn't seem very appropriate (sorry) and I updated the pull request for the cofactor multiplication in zkcrypto/bls12_381#18. Hope you'll find it useful! |
The Algorand implementation intentionally avoids using endomorphisms because of the GLV patent (which expires outside the US in December, and in the US next September). What's implemented there is compatible with Budroni and Pintore. When the patent expires, one assumes they will bring back the faster method. |
@kwantam I see, thanks for explaining! |
Interesting, I suppose any IRTF calls for adoption should either leave this part as an implementation detail internal to a subgroup check, or else wait until patent expiration then too? |
@burdges the strategy right now is the former: it's an implementation detail. In hash-to-curve, suites specify For subgroup checks, BLS just says you have to do it, not how. One can always do it via scalar multiplication by the group order; people can optimize if they want to, but it doesn't change compatibility. Fortunately, this won't be a problem much longer! |
Hashing to G1/G2/Fr/Fq/Fq2 -- with total domain separation.
The text was updated successfully, but these errors were encountered: