search

scipr-lab / libsnark

C++ library for zkSNARKs
Other
1.81k stars 579 forks source link

Change BN128 to use 448-bit field size #29

Open ebfull opened 8 years ago

ebfull commented 8 years ago

Recent research (https://ellipticnews.wordpress.com/2016/05/02/kim-barbulescu-variant-of-the-number-field-sieve-to-compute-discrete-logarithms-in-finite-fields/) suggests that a 448-bit field size may be necessary to achieve sufficient security.

In any case, it may be necessary to change BN128, and echoing #27 make it easier to change this field size later again.

daira commented 8 years ago

Although this says "change BN128...", it would be quite confusing and incompatible to literally change which curve is designated by the -DCURVE_[ALT_]BN128 compilation option. The new curve should be called something else. I suggest naming it after the field size (i.e. 448) rather than the intended security level, because the achieved security level is always subject to advances in attacks.

daira commented 8 years ago

Actually, I believe the name BN128 is already ambiguous between the two curves mentioned in the ate-pairing readme. For consistency with the names used there, we could call the new curve (or more precisely pairing) something like CurveSNARK448.

daira commented 8 years ago

I raised this at today's zdep meeting: if generating a suitable secure curve will take some time, can we have a (potentially insecure) curve that is expected to have the same performance as the eventual one, so that we can use it purely for benchmarking?

zookozcash commented 8 years ago

https://github.com/zcash/zcash/issues/714#issuecomment-218507620

ebfull commented 8 years ago

https://github.com/scipr-lab/ecfactory seems like fantastic progress toward a new curve.