7.3 KiB
BLS12-381
Elliptic Curves
Elliptic curves are an important tool in modern cryptography. If we instantiate some (appropriately designed) elliptic curve over a finite field \mathbb{F}_p$of prime characteristicp, the points on this curve are elements of a [group](https://en.wikipedia.org/wiki/Group_(mathematics) \mathbb{G}for which the [discrete logarithm problem](https://en.wikipedia.org/wiki/Discrete_logarithm) is believed to be difficult. In other words, given arbitraryg, h \in \mathbb{G}it should be difficult to computelog_g(h)$.
We sometimes make stronger assumptions about elliptic curves in order to build useful tools. For instance, the computational Diffie-Hellman assumption implies that given arbitrary $g, g^a, g^b, it should be difficult to find g^{ab}$. Viewed another way, "multiplying" group elements together is conjectured to be infeasible. This assumption is fundamental to Diffie-Hellman key exchange.
Related is the decisional Diffie-Hellman assumption which (roughly) implies that given arbitrary $g, g^a, g^b, hit should be difficult to determine ifh = g^{ab}$. zk-SNARKs require an elliptic curve for which this assumption does not hold, but the computational Diffie-Hellman assumption and many other assumptions do.
Pairing-friendly Elliptic Curves
Elliptic curve groups have a property called an embedding degree. Consider an elliptic curve instantiated over \mathbb{F}_p$with a subgroup of large prime orderq. The embedding degree is defined as the smallest ksuch thatq | (p^k - 1)$. Most elliptic curve constructions have very large embedding degrees.
Pairing-friendly elliptic curve constructions have an embedding degree that is still large enough that the curve is secure, but just small enough that an efficiently-computable bilinear pairing function $e : \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$ exists:
e(a \cdot g_1, b \cdot g_2) = g_{T}^{ab}
In other words, the pairing function allows us to effectively "multiply" group elements, though the result ends up in a different group \mathbb{G}_{T}, which we write multiplicatively. This allows us to break the decisional Diffie-Hellman assumption and reason about the multiplicative relationships between group elements.
Notice that the pairing function takes two different group elements \mathbb{G}_1, \mathbb{G}_2$as input. This is because practical constructions instantiate\mathbb{G}_1on a curveEover the "base field"\mathbb{F}_pand\mathbb{G}_2on a twisted curveE'over some [extension field](https://en.wikipedia.org/wiki/Field_extension)\mathbb{F}_{p^e}. We write elements of \mathbb{G}_{T}multiplicatively because they are really elements of aq-order multiplicative subgroup of \mathbb{F}_{p^k}$.
Curve Families
There are many ways to build pairing-friendly elliptic curve constructions, such as the Cocks-Pinch method. The most rigid and well-performing constructions are part of families of elliptic curves that have been discovered over the last two decades. Three of the most important families are:
- Barreto-Naehrig (BN) curves have the distinct advantage that
$E(\mathbb{F}_p)is of prime order, which reduces the cost of hashing to\mathbb{G}_1$ and deserializing group elements. BN curves were once considered perfect for the 128-bit security level, and Zcash originally launched using a BN curve called "alt_bn128". - Barreto-Lynn-Scott (BLS) curves originally seemed useful for the 192-bit security level. There are several subfamilies of BLS curves which submit very rigid curves with immediately determined curve constants and efficient extension field and twist configurations.
- Kachisa-Schaefer-Scott (KSS) curves appear to have some interesting performance and security tradeoffs, but are underexplored in the literature.
In 2016, Kim and Barbulescu discovered some optimizations to the Number Field Sieve (NFS) algorithm which reduced the conjectured security level of alt_bn128 to as little as 100-bits, under some conservative assumptions. Larger BN curves which target the 128-bit security level have much larger prime subgroup orders and relatively expensive pairings.
BLS curves with embedding degree $k = 12have the interesting property that targeting closer to 128-bits of security tends toward ideal prime subgroup ordersq \approx 2^{256}$, making them much more attractive than BN curves at this security level. The rigidity and simplicity of their parameterization and implementation is also attractive.
BLS12 Curves
BLS12 curves are parameterized by a value $xsuch that the base field moduluspand prime subgroup orderq$ can be computed by:
p(x) = (x - 1)^2 ((x^4 - x^2 + 1) / 3) + x
q(x) = (x^4 - x^2 + 1)
Given primes $pandqparameterized as above, we can construct an elliptic curveEover the prime field\mathbb{F}_pwhich contains a subgroup of orderq, and its sextic twist E'over the extension field\mathbb{F}_{p^2}. The q$-order subgroups of both elliptic curve groups give rise to an efficient pairing function.
We can find an appropriate $x$ by applying some simple criteria:
- We desire
$q < 2^{255}$ both for cheap reductions and so that the scalar field of our elliptic curve can be used for keying material in our construction. This gives rise to curves that have approximately 120 bits of security under conservative assumptions. - We desire an
\mathbb{F}_q$with a large2^n$ root of unity for performing efficient fast-Fourier transforms, which is very useful for the intense polynomial arithmetic needed in zk-SNARKs. - We desire an efficient extension field tower and twisting isomorphism. Subfamilies of BLS12 curves (where
$x \textrm{ mod } 72 = \{16, 64\}$ for our purposes) have such properties, along with immediately determined curve parameters. - We desire an
$x$ of low Hamming weight, to ensure the pairing function is efficient.
If we search for the largest curve that meets the above criteria, with the smallest Hamming weight, we discover x = -0xd201000000010000. We name this curve "BLS12-381" as it has a 381-bit base field prime $p$.
Implementations of BLS12-381
BLS12-381 has been implemented in the following libraries:
- ebfull/pairing is a pure-Rust implementation of the construction. It is undergoing audits and will be used in the Sapling network upgrade.
- RELIC contains a C implementation of the construction.