Skip to content
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

Update new_bls12_hash_function.md #966

Merged
merged 5 commits into from
Jul 4, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 33 additions & 16 deletions applications/new_bls12_hash_function.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
- **Project Name:** Implementation of the new hash function to BLS12 curves
- **Team Name:** Dmitrii Koshelev
- **Payment Address:** With your permission, I would prefer provide my Bitcoin payment address after I won the grant
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2

## Project Overview :page_facing_up:

Expand All @@ -13,11 +13,15 @@ Please provide the following:

- If the name of your project is not descriptive, a tag line (one sentence summary).

Implementation in Sage of my hash function to pairing-friendly curves BLS12 (for example, BLS12-381 or BLS12-377).
Implementation of my hash function in Sage in the general case and in Rust specifically for the curve BLS12-381.

- A brief description of your project.

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 pairing-friendly elliptic curves BLS12-381 and BLS12-377 (Barreto-Lynn-Scott). These curves and such hash functions are actively used in blockchains, namely in the BLS (Boneh-Lynn-Shacham) aggregate signature. My hash function is much faster than previous state-of-the-art ones, including the Wahby-Boneh indirect map. For instance, BLS12-377 is defined over a highly 2-adic finite field Fp (of characteristic p), hence the indifferentiable Wahby-Boneh hash function requires to apply twice the slow Tonelli-Shanks algorithm for extracting two square roots in the basic field. In comparison, the new hash function extracts only one cubic root, which can be expressed via one exponentiation in Fp. I have already checked the correctness of my results in the computer algebra system Magma. The project is dedicated to implementing the new hash function in Sage.
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. Consequently, besides my initial $10,000 reward (level 1), an additional reward for my colleague's work is required.

- An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.

Expand All @@ -41,7 +45,7 @@ Hashing to elliptic curves in the BLS (Boneh-Lynn-Shacham) aggregate signature.

- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?

Developers who will easily adopt my high-level implementation for their low-level programming languages such as Rust.
Developers who will use the new hash function in their implementations of cryptographic protocols.

- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
- If so, how is your project different?
Expand All @@ -59,7 +63,7 @@ Dmitrii Koshelev

- Names of team members

There are no other members.
My colleague who is a professional Rust programmer. He prefers to be anonymous.

### Contact

Expand Down Expand Up @@ -104,32 +108,45 @@ https://link.springer.com/article/10.1007/s10623-022-01012-8

- **Total Estimated Duration:** 6 months
- **Full-Time Equivalent (FTE):** 1 FTE
- **Total Costs:** 10,000 USD

- **Total Costs:** 15,000 USD

### Milestone 1 — Implementation of the new hash function
### Milestone 1 — An implementation in Sage

- **Estimated duration:** 6 months
- **Estimated duration:** 3 months
- **FTE:** 1
- **Costs:** 10,000 USD

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| 0a. | License | GNU GPL |
| 0b. | Documentation | I will provide **inline documentation** of the code. |
| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. Ie will describe how to run these tests. |
| 0d. | Docker | I do not intend to deliver this, because Milestone 1 is research oriented. |
| 0e. | Article | I will cite the implementation in Section 1.1 of my new article https://eprint.iacr.org/2021/1082. I would like to submit this article to the international conference https://fq15.telecom-paris.fr/index.html in Paris if it is not canceled because of COVID-19.
| 1. | Implementation | Sage implementation of the hash function described below.
| 0c. | Testing Guide | |
| 0d. | Docker | I do not intend to deliver this, because the project is research oriented. |
| 0e. | Article | I will cite the implementation and I will thank Web3 Foundation for its financial support in my new article https://eprint.iacr.org/2021/1082. I submitted this article to Journal of Cryptology. At the moment, it is under review.
| 1. | Implementation | Sage (non-constant-time) implementation of the hash function described below.

To be definite, let me use the notation of my article https://link.springer.com/article/10.1007/s10623-022-01012-8. The new hash function consists of three components: a classical one \eta: {0,1}^* -> Fp^2, a rational map \varphi: Fp^2 -> T(Fp), and an additional map h^\prime: T(Fp) -> E(Fp), where E is a given elliptic Fp-curve of j-invariant 0 and T is a suplementary algebraic threefold. A construction of \eta is represented in Section 5 of the draft https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/. This is the composition of a hash function {0,1}^* -> {0,1}^n for some n \in N and the subsequent restriction modulo p, hence we can use a standard hash function from one of Sage libraries. It remains to implement \varphi and h^\prime just as described in my article. In particular, to perform the (unique) exponentiation in Fp (arising in h^\prime) in the case of BLS12-381 curve an addition chain of quite small length has already been derived in https://github.com/dishport/Some-remarks-on-how-to-hash-faster-onto-elliptic-curves (cf. Section 1.1 of https://eprint.iacr.org/2021/1082).
To be definite, let me use the notation of my article https://link.springer.com/article/10.1007/s10623-022-01012-8. The new hash function consists of three components: a classical one \eta: {0,1}^* -> Fp^2, a rational map \varphi: Fp^2 -> T(Fp), and an additional map h^\prime: T(Fp) -> E(Fp), where E is a given elliptic Fp-curve of j-invariant 0 and T is a suplementary algebraic threefold. A construction of \eta is represented in Section 5 of the draft https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/. This is the composition of a hash function {0,1}^* -> {0,1}^n for some n \in N and the subsequent restriction modulo p, hence we can use a standard hash function from one of cryptographic libraries. It remains to implement \varphi and h^\prime just as described in my article.

...
It is also worth noting that the new hash function is relevant for any ordinary (i.e., non-supersingular) elliptic Fq-curve y^2 = x^3 + b (of j-invariant 0) such that the square root of b lies in Fq. Here Fq is an arbitrary finite field (of characteristic p > 3) for which 3 divides q-1, but 27 does not. Therefore, our Sage implementation is in fact relevant for all such curves and fields. The BLS12-381 curve corresponds to the case when q = 10 (mod 27) and b is not a cubic residue in Fq.

### Milestone 2 — A non-constant-time implementation in Rust in the case of the BLS12-381 curve

- **Estimated duration:** 3 months
- **FTE:** 1
- **Costs:** 5,000 USD

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| 0a. | License | Apache License, Version 2.0 and MIT license |
| 0b. | Documentation | I will provide **inline documentation** of the code. |
| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. I will describe how to run these tests. |
| 0d. | Docker | I do not intend to deliver this, because the project is research oriented. |
| 0e. | Article | I will cite the implementation and I will thank Web3 Foundation for its financial support in my new article https://eprint.iacr.org/2021/1082. I submitted this article to Journal of Cryptology. At the moment, it is under review.
| 1. | Implementation | Rust non-constant-time implementation of the new hash function for BLS12-381. It is suggested to use the library arkworks (https://github.com/arkworks-rs/curves) as a base. In particular, to perform the (unique) exponentiation in Fp an addition chain of quite small length has already been derived in https://github.com/dishport/Some-remarks-on-how-to-hash-faster-onto-elliptic-curves (cf. Section 1.1 of https://eprint.iacr.org/2021/1082).

## Future Plans

The new hash function appears to be optimal, because it performs only one exponentiation in the basic field Fp. In other words, since it is highly unlikely that there is a hash function to an elliptic curve without exponentiations at all (even if it is supersingular), the result of my article seems to be unimprovable. Thus I hope that the implementation of my hash function will be interesting not only to you, but also to all blockchain projects that involve the BLS signature.
The new hash function appears to be optimal, because it performs only one exponentiation in the basic field Fq. In other words, since it is highly unlikely that there is a hash function to an elliptic curve without exponentiations at all (even if it is supersingular), the result of my article seems to be unimprovable. Thus I hope that the implementation of my hash function will be interesting not only to you, but also to all blockchain projects that involve the BLS signature.

## Additional Information :heavy_plus_sign:

Expand Down