Change BN128 to use 448-bit field size

[ebfull]

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]

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]

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]

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]

zcash/zcash#714 (comment)

[ebfull]

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