Implement BN curves

[yelhousni]

This PR implements infrastructure for BN family of curves and instantiate BN256 from Etherem (EDIT: curve renamed to BN254).
Type: Feature
Label: Ready to review
Priority: Medium

Motivation

Support of BN family that is widely used for pairing-based cryptography (Ethereum, libsnark, DIZK, Halo).

Followups

• Instantiate BN254b from DIZK
• Instantiate BN382 from o1-labs for Halo-like recursion

[yelhousni]

@Pratyush @howardwu @kobigurk That would be great if you can review this!

[Pratyush]

Looks great, just some naming suggestions (bn256 -> bn254).

(Should be accompanied by renaming the file in the file-system)

[Pratyush]

Do we know what the cofactor is?

[yelhousni]

Yes, in sage:

q=21888242871839275222246405745257275088696311157297823662689037894645226208583
Fq=GF(q)
E=EllipticCurve(Fq,[0,3])
ZZ.<z>=Fq[]
Fq2.<u>=GF(q^2, modulus=z^2+1)
Et=EllipticCurve(Fq2,[0,3/(9+u)])
cofactor = Et.order() // E.order()

[mratsim]

The order on G2 for BN curves is r∗(2p−r) with r the G1 curve order, so the G2 cofactor is always (2p-r)

[yelhousni]

Yes indeed. Here is a good explanation on why: https://crypto.stackexchange.com/questions/64064/order-of-twisted-curve-in-pairings

[Pratyush]

Thanks for the helpful chronology! Given this info, what do you suggest we should name the curve? I think bn256 doesn’t make sense if there are two different curves with that name.

…

On Sat, Jun 20, 2020 at 11:26 AM Kobi Gurkan ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In algebra/Cargo.toml <#225 (comment)>: > + "bn256", "bls12_377", "bls12_381", "cp6_782", "bw6_761", "mnt4_298", "mnt4_753", "mnt6_298", "mnt6_753", "ed_on_bls12_377", "ed_on_cp6_782", "ed_on_bw6_761", "ed_on_bls12_381", "ed_on_mnt4_298", "ed_on_mnt4_753" ] +bn256 = [] If I remember correctly, the history goes like this: - bn256 from cloudflare and google implement a BN curve that's unrelated to Zcash. When the Ethereum devs ported it to the libsnark curve, they kept the name. - bn128 is the name that was used by libsnark and then by Zcash, denoting 128-bit security. - Later on, Zcash and the community mostly decided to switch to the bn254 naming, since it wasn't 128-bit security anymore and 254-bit is the size of the curve. I believe that the pairing-friendly curve draft from IETF actually calls this curve BN_SNARK1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#225 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYSJ6WBXRWASFVGALDFABDRXT5M5ANCNFSM4OBLVEBA> .

[kobigurk]

IMO bn254.

[Pratyush]

Ok sounds good then!

[yelhousni]

Thank you Kobi for the chronology! If we are to choose the name that makes most sense, then bn254 is the best option indeed. We just need to mention (in mod.rs for instance) that the curve is known also as bn256 in Geth and bn128 in libff.

[mratsim]

For naming I suggest BN254_Snarks as in the literature BN254 often (always?) refers to the one from Nogami et al with parameter -(2^62 + 2^55 + 1)

MCL also uses similar scheme to differentiate both: https://github.com/herumi/mcl#support-curves

[Pratyush]

Hey @mratsim, thanks for the additional perspective!

I still feel that bn254 is fine as it is well known in the context of SNARK systems (which this library is largely targeted towards). I also think that the literature moving forward will probably not use any BN254 curve, as these curves are not secure. For the same reason, existing systems will probably eventually be deprecated the curve anyway.

[Pratyush]

LGTM!