0
$\begingroup$

JPBC library describes 6 types of elliptic curves. This is how they describe type A:

Type A pairings are constructed on the curve $y^2=x^3+x$ over the field $\mathbb{F}_q$ for some prime $q=3 \mod 4$ . Both $\mathbb{G}_1$ and $\mathbb{G}_2$ are the group of points $E(\mathbb{F}_q)$ , so this pairing is symmetric. The order $r$ is some prime factor of $q+1$ .

They also offer a curve generator implementation that takes in rBits and qBits values and calculates the q,r,h, exp1, exp2 values.

I would like to know, what rBits and qBits values consider to be secure enough for cryptocurrency wallet security? Also, what is the best type that provides the mentioned security and has the best performance?

I recently implemented BLS signature aggregation using JPBC, and I would like to know what would be the best settings to use in cryptocurrency application that will use it?

$\endgroup$
3
$\begingroup$

Since $\mathbb{G}_T$ is $\mathbb{F}_{q^2}$ in the setting you are mentioning, you would have to choose them so large that your implementation will no longer have the performance one would hope for.

I would recommend to switch to the asymmetric setting. Currently the probably best choice regarding performance and existence of optimised implementations is to use BN parings. However, recent progress in solving the discrete log problem in prime extension fields suggests that BLS curves might be an even better choice (see here). In the aforementioned paper you can also find estimations on the impact of the recent improvements on the key length. For BN pairings these estimations suggest that it is required to increase the bit length of $p$ to 461 bit for 128 bit security. There is also an alternative estimation which suggests that it is sufficient to use $p$ of length 383 bits for 128 bit security. The conservative choice would thus be 461 bit.

I would probably also use another library - as far as I know JPBC is not the best choice regarding performance. There are various Java implementations for BN pairings available. One option would be to rely on the bnpairings library. Another option would be to go for the ECCelerate library, which is free for educational and research purposes, and also provides a very recent and highly optimised implementation of BN pairings. Since you mentioned that you implemented BLS signatures: it might also be interesting for you that ECCelerate already offers means to hash to the groups as required by BLS signatures. I don't know whether this is implemented in the BNpairings library.

$\endgroup$
  • $\begingroup$ It's been 5 days now, and I am still searching, lol. bnpairings is a very old library with lack of documentation, so I wasn't been able to test it well. ECCelerate got relatively very fast pairing implementation, but I don't know how to implement BLS there, I don't know how to generate the public and private keys for starter... I found ed25519 to be very interesting, but it's batch verification does not support aggregation. Do you aware of any other BLS implementations? If it's C/C++ I can do JNI wrapping. I am lost, please help me. $\endgroup$ – Ilya Gazman Feb 8 '18 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.