libsnark
libsnark copied to clipboard
scipr-lab
Change BN128 to use 448-bit field size
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.
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.
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.
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?
https://github.com/scipr-lab/ecfactory seems like fantastic progress toward a new curve.