Update new_bls12_hash_function.md #966
Conversation
|
Hi again @dishport, thanks for the amendment.
In that case, I think instead of replacing your current Sage implementation in the deliverables, it would make more sense to leave it and add the Rust version in addition to it. @burdges and @drskalman will also take a look at this PR, if they agree maybe we could accept it in the current state with the Rust implementation having full test coverage and any other requirements the Sage one doesn't fulfill. |
@alxs, I cannot change my W3F Grant Proposal. It says that "You must be on a branch to make or propose changes to this file". Please help me. |
|
@dishport you should be able to update it here https://github.com/dishport/Grants-Program/blob/patch-1/applications/new_bls12_hash_function.md |
@alxs, thanks! I updated the project. I divided it into 3 milestones, including a constant-time implementation in Rust. |
|
@dishport thanks! I personally don't see the need for a constant-time implementation as long as we don't have an application for it in mind, but I'll follow @burdges and @drskalman's lead if they do. |
@alxs, Will it be sufficient ? I see "At least 5 approving reviews are required by reviewers with write access". |
|
@dishport only approvals by members of the committee count. We're currently waiting for an opinion from the aforementioned two members of our research team. For this grant level, only 3 approvals are required - please disregard Github's merge requirements. |
|
I'm on vacation right now, but yeah I'd go with whatever @drskalman says here. I'll make further comments in matrix. I do not see any problem with supporting it in principle, but we cannot really assess the constant time part, so it needs to be finished off by some posts to mailing lists with more qualified peoples, like IRTF CFRG and also the hash-to-curve folk |
@burdges, do you know if @drskalman is also on vacation ? He does not answer for some reason.
I would be grateful to you if you could help to establish contact with these peoples. I tried to start a dialogue with hash-to-curve folk here and by email, but they do not want to develop the dialogue. |
I agree with @alxs points. As such milstone 3 (constant time) needs to be dropped and test coverage moves to milestone 2. Plus adding a note about modularity of Sage implementation and its generalizabiliy to other curves. Thanks a lot. |
|
It appears they were not interested in replacing any hash-to-curves in the current IRTF RFC then? Alright, thanks for proding them. We should "glue together" your comments in cfrg/draft-irtf-cfrg-hash-to-curve#316 into an email to the IRTF CFRG list https://irtf.org/cfrg so that more people know about your work. I think this is all we need to do on publicity. I think @drskalman still needs to review in code documentation and tests, but then that's it afaik. |
|
I will update the project soon. Meanwhile, you can see a non-constant-time implementation in Rust of my colleague. The new hash function is actually faster than SWU one. He is not able to compare with Wahby-Boneh hash, because the latter is not yet implemented in arkworks. He used this library as a base. |
|
I updated the project. |
@burdges, you write "we". Could you help me to prepare a good email to the IRTF CFRG list ? Maybe even to write on your behalf. I guess, your opinion will be much more authoritative for people. |
|
Thanks for the updates @dishport, looks good. Just to make sure, since there are no changes to the Sage delivery: are you ok with addressing @drskalman's remaining feedback on your current delivery? Otherwise, I think this is what he meant by "adding a note about modularity of Sage implementation and its generalizabiliy to other curves". Please mention in the specification of the Sage implementation if there's any feedback you're not planning to address. |
@alxs, in comparison with the delivery, I commented on the Sage implementation in detail. Besides, I added to the project description (the section about future plans) a note about modularity of Sage implementation and its generalizability to other curves, as @drskalman asked. I stress in the project that it is primarily dedicated to the curve BLS12-381. So I'm required to implement the hash function only to this curve. Although my code is actually relevant when q = 10 (mod 27) and b is not a cubic residue in Fq, where Fq is a finite field and a curve has the form y^2 = x^3 + b. |
|
yes sure, send me/us a quick draft and I make comments, or even post it here. The IRTF CFRG list mail could be roughly what you wrote above I think. It just need to give some idea why you think this has advantages over what exists, and link to the repositories. |
|
Dear IRTF CFRG committee, My name is Dimitri Koshelev. I am a postdoctoral researcher in one of Paris universities. My research is dedicated to (mathematical methods of) elliptic cryptography. Recently, my article was published in the quite famous cryptographic journal "Designs, Codes and Cryptography". This article provides a new hash function H (indifferentiable from a random oracle) to many elliptic curves y^2 = x^3 + b (of j-invariant 0), including most pairing-friendly curves of the family BLS12 (Barreto-Lynn-Scott) of embedding degree 12. Such curves and hash functions are actively used in numerous protocols such as the BLS (Boneh-Lynn-Shacham) aggregate signature. My hash function H is much faster than previous state-of-the-art ones, including the Wahby-Boneh indirect map to the curve BLS12-381. As is known, this curve is a de facto standard in today's real-world pairing-based cryptography. The indifferentiable Wahby-Boneh hash function requires to extract two square roots (i.e., to compute two exponentiations) in the basic field Fp. In comparison, H extracts only one cubic root, which can be also expressed via one exponentiation in Fp. And according to Section 1.1 of my other article the exponentiations for square and cubic roots in Fp have short addition chains of about the same length. You can see a low-level implementation in Rust of my colleague. The new hash is actually more efficient than the universal SW (Shallue-van de Woestijne) hash. The colleague is not able to compare with the Wahby-Boneh hash, because the latter is not yet implemented in arkworks. He used this library as a base. At the same time, H appears to be unimprovable, because it is highly unlikely that there is a hash function to an elliptic curve without exponentiations at all (even if it is supersingular). As you know, there is the regularly updated CFRG draft on hashing to elliptic curves. I would be very grateful to you, if you could express your opinion. Does the new hash function deserve to be included in the draft ? Best regards, |
@burdges, please make remarks on my email above. |
Then, doesn't it makes more sense to move the sage implementation to a future grant?
My understanding is that the Sage code was intended for research purposes (and not for production), and the code in its current condition serves that cause very little if any. My suggestion would be to remove the Sage code delivery and its cost from the first deliverable and postpone its delivery to a future grant application when it is possible to produce a reusable code. |
@drskalman, thank you for your remarks. Your first sentence "Plus adding a note about modularity of Sage implementation and its generalizabiliy to other curves." was not clear enough for me. I updated the project, taking into account a general implementation in Sage, but an implementation in Rust only for bls12-381. Now is the project normal ? Could you accept it in this form ? |
alxs
added
the
ready for review
|
@dishport thanks for clarifying this. In that case, if I understood correctly you will continue working on the Sage implementation and get back to @drskalman on the delivery when it is ready for review? |
@alxs, I have just written a general implementation in Sage: @drskalman, could you verify it ? Or do I have to make a delivery first? |
|
It's just slightly more formal and promotional than typical list traffic, but otherwise fine: Dear CRFG participants, As this is the broadest form for discussing the CFRG hash-to-curve draft, I wanted to mention my optimizations of indifferentiable hashing onto prime order subgroups of many ordinary elliptic curves over prime fields. You'll find the paper on the IACR eprint server or published at DCC. We need an elliptic curve of the form y^2 = x^3 + b (of j-invariant 0), including most pairing-friendly curves of the family BLS12 (Barreto-Lynn-Scott) of embedding degree 12. Hash functions to such curves are actively used in numerous protocols such as the BLS (Boneh-Lynn-Shacham) aggregate signature. My hash function H is much faster than previous state-of-the-art ones, including the Wahby-Boneh indirect map to the curve BLS12-381. As is known, this curve is a de facto standard in today's real-world pairing-based cryptography. The indifferentiable Wahby-Boneh hash function requires to extract two square roots (i.e., to compute two exponentiations) in the basic field Fp. In comparison, H extracts only one cubic root, which can be also expressed via one exponentiation in Fp. And according to Section 1.1 of my other article the exponentiations for square and cubic roots in Fp have short addition chains of about the same length. You can see a low-level implementation in Rust of my colleague. The new hash is actually more efficient than the universal SW (Shallue-van de Woestijne) hash. The colleague is not able to compare with the Wahby-Boneh hash, because the latter is not yet implemented in arkworks. He used this library as a base. At the same time, H appears to be unimprovable, because it is highly unlikely that there is a hash function to an elliptic curve without exponentiations at all (even if it is supersingular). Is there much interest in including this hash function in the CFRG hash-to-curve draft? Best regards, |
|
@dishport thanks for clarifying. For our records, we'd prefer to have it as a delivery. But you can just update your current one w3f/Grant-Milestone-Delivery#376 I'll approve the amendment and share it with the rest of the team. |
@alxs, I updated the delivery. But I am not sure that it is located in the correct place of GitHub: |
|
Thanks @dishport, yes you can see the file in your delivery PR has been updated https://github.com/w3f/Grant-Milestone-Delivery/pull/376/files |
Project Abstract
Recently, my article https://link.springer.com/article/10.1007/s10623-022-01012-8 was published in the quite prestigious cryptographic journal "Designs, Codes and Cryptography". This article provides a new hash function (indifferentiable from a random oracle) to the subgroup G1 of many elliptic curves of j-invariant 0, including most pairing-friendly curves of the family BLS12 (Barreto-Lynn-Scott) of embedding degree 12. Such curves and hash functions are actively used in blockchains, namely in the BLS (Boneh-Lynn-Shacham) aggregate signature. According to the web page https://wiki.polkadot.network/docs/learn-keys, the BLS signature will be in particular used in Polkadot.
My hash function is much faster than previous state-of-the-art ones, including the Wahby-Boneh indirect map to the curve BLS12-381. This curve is a de facto standard in today's real-world pairing-based cryptography. The indifferentiable Wahby-Boneh hash function requires to extract two square roots (i.e., to compute two exponentiations) in the basic field Fp. In comparison, the new hash function extracts only one cubic root, which can be also expressed via one exponentiation in Fp. And according to Section 1.1 of my other article https://eprint.iacr.org/2021/1082 the exponentiations for square and cubic roots in Fp have short addition chains of about the same length.
I have already checked the correctness of my results in the computer algebra system Magma. The new project is dedicated to an implementation of the new hash function to BLS12-381 in Rust. This project is a follow-up of the previous one concerning a proof-of-concept implementation in Sage (see #825). I wrote such an implementation, but I didn't finish the project, because my code does not meet high standards of Web3 Foundation. However, I found a professional developer in Rust who is ready to provide a Rust implementation (based on my Sage one), including tests and a documentation. Consequently, besides my initial $10,000 reward (level 1), an additional reward for my colleague's work is required.
For which grant level are you applying?
Application Checklist
project_name.md) and updated.@_______How Did You Hear About our grants program?
#825