]> GMO CONNECT Inc.

sakemi-yumi@gmo-connect.jp

GMO CONNECT Inc.

kanno@gmo-connect.jp

Carnegie Mellon University

rsw@cs.stanford.edu

IRTF CFRG Internet-Draft Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and they can be applied to construct several cryptographic protocols such as identity-based encryption, attribute-based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security; however, its security level is estimated at approximately 100 bits due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. This memo also specifies the serialization and deserialization of the points and scalars that protocols exchange, restating a format that is already in widespread use, and states which of the remaining decisions belong to the calling protocol.

Introduction

Pairing-Based Cryptography Elliptic curve cryptography is an important area in currently deployed cryptography. The cryptographic algorithms based on elliptic curve cryptography, such as the Elliptic Curve Digital Signature Algorithm (ECDSA), are widely used in many applications. Pairing-based cryptography, a subfield of elliptic curve cryptography, has attracted much attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves. Pairings are fundamental in the construction of several cryptographic algorithms and protocols such as identity-based encryption (IBE), attribute-based encryption (ABE), authenticated key exchange (AKE), short signatures, and so on. Several applications of pairing-based cryptography are currently in practical use. As the importance of pairings grows, elliptic curves where pairings are efficiently computable are studied and the special curves called pairing-friendly curves are proposed.

Applications of Pairing-Based Cryptography Several applications using pairing-based cryptography have already been standardized and deployed. We list here some examples of applications available in the real world. IETF published RFCs for pairing-based cryptography such as Identity-Based Cryptography , Sakai-Kasahara Key Encryption (SAKKE) , and Identity-Based Authenticated Key Exchange (IBAKE) . SAKKE is applied to Multimedia Internet KEYing (MIKEY) and used in 3GPP . Pairing-based key agreement protocols are standardized in ISO/IEC . In , a key agreement scheme by Joux , identity-based key agreement schemes by Smart-Chen-Cheng and Fujioka-Suzuki-Ustaoglu are specified. MIRACL implements M-Pin, a multi-factor authentication protocol . The M-Pin protocol includes a type of zero-knowledge proof, where pairings are used for its construction. The Trusted Computing Group (TCG) specified the Elliptic Curve Direct Anonymous Attestation (ECDAA) in the specification of a Trusted Platform Module (TPM) . ECDAA is a protocol for proving the attestation held by a TPM to a verifier without revealing the attestation held by that TPM. Pairings are used in the construction of ECDAA. FIDO Alliance and W3C also published an ECDAA algorithm similar to TCG. Intel introduced Intel Enhanced Privacy ID (EPID) that enables remote attestation of a hardware device while preserving the privacy of the device as part of the functionality of Intel Software Guard Extensions (SGX) . They extended TPM ECDAA to realize such functionality. A pairing-based EPID was proposed and distributed along with Intel SGX applications. Zcash implemented their own zero-knowledge proof algorithm named Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARKs) . zk-SNARKs are used for protecting the privacy of transactions of Zcash. They use pairings to construct zk-SNARKs. Cloudflare introduced Geo Key Manager to restrict distribution of customers' private keys to a subset of their data centers. To achieve this functionality, ABE is used, and pairings take a role as a building block. In addition, Cloudflare published a new cryptographic library, the Cloudflare Interoperable, Reusable Cryptographic Library (CIRCL) in 2019. CIRCL now includes pairing computations on BLS12-381 (see ). Currently, Boneh-Lynn-Shacham (BLS) signature schemes are being standardized and utilized in several blockchain projects such as Ethereum , Chia Network , and DFINITY . The aggregation functionality of BLS signatures is effective for their applications of decentralization and scalability.

Motivation and Contribution At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve (NFS) algorithm for the discrete logarithm problem in a finite field GF(p^k) , where p is a prime and k is the embedding degree (). The attack improves the polynomial selection that is the first step in the number field sieve algorithm for discrete logarithms in GF(p^k). The idea is applicable when the embedding degree k is a composite that satisfies k = i * j with gcd(i, j) = 1 and i, j > 1. The basic idea is based on the equality GF(p^k) = GF((p^i)^j) and one of the improvements for reducing the amount of cost for solving the discrete logarithm problem is using subfield calculation. Several types of pairing-friendly curves such as Barreto-Naehrig curves (BN curves) and Barreto-Lynn-Scott curves (BLS curves) are affected by the attack, since a pairing-friendly curve suitable for cryptographic applications requires that the discrete logarithm problem is sufficiently difficult. Please refer to for detailed ideas and calculation algorithms of the attack. In particular, BN254, which is a BN curve with a 254-bit characteristic effective for pairing calculations, was adopted by a lot of cryptographic libraries as a parameter of the 128-bit security level; however, the security level of BN254 is estimated at approximately 100 bits due to the effect of the attack , where the security levels described in this memo correspond to the security strength of NIST recommendation . To resolve this effect immediately, several research groups and implementers re-evaluated the security of pairing-friendly curves and they respectively proposed various curves that are secure against the attack . In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in international standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", pairing-friendly curves corresponding to each security level are selected in accordance with the security evaluations summarized in and . As a result, we recommend the BLS curve with 381-bit characteristic of embedding degree 12 and the BN curve with the 462-bit characteristic for the 128-bit security level, and the BLS curves of embedding degree 48 with the 581-bit characteristic for the 256-bit security level. This memo shows their specific test vectors. On the other hand, we do not show the parameters for 192-bit security here because there are no curves that match our selection policy. This memo also specifies how the points and scalars that protocols exchange are serialized and deserialized. That format does not originate here: it comes from and is already relied upon by other specifications, which cite this document for it. It is restated normatively in , together with what makes a deserialized value valid and which decisions are left to the calling protocol. Point serialization is given for BLS12-381 and BLS48-581; scalar serialization applies to all three curves.

Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Preliminaries

Elliptic Curves Let p be a prime number at least 5, and let q be a power of p. Let GF(q) be the finite field with q elements. The curve defined by the following equation E is called an elliptic curve: and a and b in GF(q) satisfy the discriminant inequality 4 * a^3 + 27 * b^2 != 0 in GF(q). This is called the Weierstrass normal form of an elliptic curve. A solution (x,y) to the equation E can be thought of as a point on the corresponding curve. We define the set of GF(q)-rational points of E, denoted by E(GF(q)), to be the set of all solutions (x,y) in GF(q), together with a 'point at infinity' O_E, which is defined to lie on every vertical line passing through the curve E. Since a and b are also elements of every extension field of GF(q), the same definition gives the rational points of E over any such field; for example, E(GF(p^k)) for a curve E defined over GF(p), as used in . The set E(GF(q)) forms a group under a group law that can be defined geometrically as follows. For P and Q in E(GF(q)) define P + Q to be the reflection around the x-axis of the unique third point R of intersection of the straight line passing through P and Q with the curve E. If the straight line is tangent to E, we say that it passes through that point twice. The identity of this group is the point at infinity O_E. We also define scalar multiplication [K]P for a positive integer K as the point P added to itself (K-1) times. Here, [0]P becomes the point at infinity O_E and the relation [-K]P = -([K]P) is satisfied.

Pairings A pairing is a bilinear map defined on two subgroups of rational points of an elliptic curve. Examples include the Weil pairing, the Tate pairing, the optimal ate pairing , and so on. The optimal ate pairing is considered to be the most efficient to compute and is the one that is most commonly used for practical implementation. Let E be an elliptic curve defined over a prime field GF(p), and let r be a large prime dividing the order of E(GF(p)). Let k be the minimum integer for which r is a divisor of p^k - 1; this is called the embedding degree of E over GF(p). Let pi be the p-power Frobenius endomorphism, which maps a point (x, y) of E to (x^p, y^p), and let E(GF(p^k))[r] be the r-torsion subgroup of E(GF(p^k)). The pairing is defined on the two subgroups where, for an integer K, ker(pi - [K]) denotes the set of points T with pi(T) = [K]T. For the curves considered in this document, both G_1 and G_2 have order r. G_2 is identified by the eigenvalue p, and not merely as an order r subgroup of E(GF(p^k)): that weaker description is satisfied by G_1 as well, and the pairing computed in is degenerate when both of its arguments are taken from G_1. Let d be a divisor of k and E' be an elliptic curve defined over GF(p^(k/d)). If there is an isomorphism psi from E'(GF(p^k)) to E(GF(p^k)), then E' is called the twist of E. It is more efficient to hold elements of G_2 as points of E'(GF(p^(k/d))), whose coordinates lie in a smaller field. Write G'_2 for the preimage of G_2 under psi, that is, the set of points Q of E'(GF(p^(k/d))) with psi(Q) in G_2. For the curves in this document, G_2 lies in the image of E'(GF(p^(k/d))) under psi, which is what makes that representation possible; since psi is injective, G'_2 is a subgroup of order r, and psi restricted to G'_2 is an isomorphism onto G_2. The formula for psi is given for each curve in . What is given there is the restriction of psi to E'(GF(p^(k/d))), which is an injective homomorphism into E(GF(p^k)) and not an isomorphism, since E'(GF(p^(k/d))) and E(GF(p^k)) differ in size. The formula is the same in either case. Where a point of G_2 is written with coordinates in this document, as in and in , it is the corresponding point of G'_2 that is written; psi carries it back to G_2 when the pairing is evaluated. The exception is , where G_2 points are written in untwisted coordinates on E(GF(p^k)). Let G_T be an order r subgroup of the multiplicative group (GF(p^k))^*; this exists by definition of k. A pairing is defined as a bilinear map e: (G_1, G_2) -> G_T satisfying the following properties:

1. Bilinearity: for any S in G_1, T in G_2, and integers K and L, e([K]S, [L]T) = e(S, T)^{K * L}.
2. Non-degeneracy: for every T in G_2 other than O_E, e(S, T) = 1 if and only if S = O_E; and for every S in G_1 other than O_E, e(S, T) = 1 if and only if T = O_E. The identity element has to be excluded on both sides: by bilinearity, e(S, O_E) = 1 holds for every S in G_1, and e(O_E, T) = 1 for every T in G_2.

In applications, it is also necessary that for any S in G_1 and T in G_2, this bilinear map is efficiently computable. We define some of the terminology used in this memo as follows:

GF(p):

a finite field with characteristic p.

GF(p^k):

an extension field of degree k.

(GF(p))^*:

the multiplicative group of GF(p).

(GF(p^k))^*:

the multiplicative group of GF(p^k).

b:

the coefficient of the curve equation E: y^2 = x^3 + b.

O_E:

the point at infinity over an elliptic curve E.

E(GF(p^k)):

the group of GF(p^k)-rational points of E.

#E(GF(p^k)):

the number of GF(p^k)-rational points of E.

r:

the order of G_1 and G_2.

E(GF(p^k))[r]:

the r-torsion subgroup of E(GF(p^k)), that is, the set of points T of E(GF(p^k)) with [r]T = O_E.

pi:

the p-power Frobenius endomorphism, which maps a point (x, y) of E to (x^p, y^p).

BP:

a point in G_1. (The 'base point' of a cyclic subgroup of G_1)

h:

the cofactor h = #E(GF(p)) / r, where gcd(h, r) = 1.

h':

the cofactor h' = #E'(GF(p^(k/d))) / r, where gcd(h', r) = 1.

BP':

a point in G'_2. (The 'base point' of a cyclic subgroup of G'_2)

Barreto-Naehrig Curves A BN curve is a family of pairing-friendly curves proposed in 2005. A pairing over BN curves constructs optimal ate pairings. A BN curve is defined by elliptic curves E and E' parameterized by a well-chosen integer chi. E is defined over GF(p), where p is a prime number and at least 5, and E(GF(p)) has a subgroup of prime order r. The characteristic p and the order r are parameterized by for an integer chi. The elliptic curve E has an equation of the form E: y^2 = x^3 + b, where b is a nonzero element of GF(p) chosen so that #E(GF(p)) = r. In the case of BN curves, we can use twists of the degree 6. If nu is an element that is neither a square nor a cube in an extension field GF(p^2), the twist E' of E is defined over an extension field GF(p^2) by the equation E': y^2 = x^3 + b' with b' = b / nu or b' = b * nu. BN curves are called D-type if b' = b / nu, and M-type if b' = b * nu. The embedding degree k is 12. A pairing e is defined by taking G_1 as a subgroup of E(GF(p)) of order r, G_2 as defined in and represented by the subgroup G'_2 of E'(GF(p^2)), and G_T as an order r subgroup of the multiplicative group (GF(p^12))^*.

Barreto-Lynn-Scott Curves A BLS curve is another family of pairing-friendly curves proposed in 2002. Similar to BN curves, a pairing over BLS curves constructs optimal ate pairings. A BLS curve is defined by elliptic curves E and E' parameterized by a well-chosen integer chi. E is defined over a finite field GF(p) by an equation of the form E: y^2 = x^3 + b, and its twist E': y^2 = x^3 + b' is defined in the same way as for BN curves, with nu and E' over GF(p^2) for BLS12 and over GF(p^8) for BLS48. In contrast to BN curves, E(GF(p)) does not have a prime order. Instead, its order is divisible by a large parameterized prime r and denoted by h * r with cofactor h. The pairing is defined on the r-torsion points. In the same way as BN curves, BLS curves can be categorized as D-type and M-type. BLS curves vary in accordance with different embedding degrees. In this memo, we deal with the BLS12 and BLS48 families with embedding degrees 12 and 48 with respect to r, respectively. In BLS curves, parameters p and r are given by the following equations: for a well chosen integer chi where chi must be 1 (mod 3). A pairing e is defined by taking G_1 as a subgroup of E(GF(p)) of order r, G_2 as defined in and represented by the subgroup G'_2 of E'(GF(p^2)) for BLS12 and of E'(GF(p^8)) for BLS48, and G_T as an order r subgroup of the multiplicative group (GF(p^12))^* for BLS12 and of the multiplicative group (GF(p^48))^* for BLS48.

Security of Pairing-Friendly Curves

Evaluating the Security of Pairing-Friendly Curves The security of pairing-friendly curves is evaluated by the hardness of the following discrete logarithm problems:

• The elliptic curve discrete logarithm problem (ECDLP) in G_1 and G_2
• The finite field discrete logarithm problem (FFDLP) in G_T

There are other hard problems over pairing-friendly curves used for proving the security of pairing-based cryptography. Such problems include the computational bilinear Diffie-Hellman (CBDH) problem, the bilinear Diffie-Hellman (BDH) problem, the decision bilinear Diffie-Hellman (DBDH) problem, the gap DBDH problem, etc. . Almost all of these variants are reduced to the hardness of discrete logarithm problems described above and are believed to be easier than the discrete logarithm problems. Pairing inversion is a related problem: given P in G_1 other than O_E and an element of G_T, find Q in G_2 such that e(P, Q) equals that element, or the same with the roles of G_1 and G_2 exchanged. Solving it for one of the two arguments is enough to solve a variant of the BDH problem . Solving the discrete logarithm problem in G_T also solves pairing inversion. examines approaches that invert the two stages of the pairing computation, Miller's algorithm and the final exponentiation, as well as approaches that invert the pairing in one step, and finds that none of them solves pairing inversion for curves of cryptographic interest. Although it would be sufficient to attack any of these problems to attack pairing-based cryptography, the only known attacks thus far attack the discrete logarithm problem directly, so we focus on the discrete logarithm in this memo. The security levels of pairing-friendly curves are estimated by the computational cost of the most efficient algorithm for solving the above discrete logarithm problems. The best-known algorithms for solving the discrete logarithm problems are based on Pollard's rho algorithm and Index Calculus . To make index calculus algorithms more efficient, number field sieve (NFS) algorithms are utilized.

Impact of Recent Attacks In 2016, Kim and Barbulescu proposed a new variant of the NFS algorithms, the extended tower number field sieve (exTNFS), which drastically reduces the complexity of solving FFDLP . The exTNFS improves the polynomial selection that is the first step in the number field sieve algorithm for discrete logarithms in GF(p^k). The idea is applicable when the embedding degree k is a composite that can be written as k = i * j with gcd(i, j) = 1 and i, j > 1. Any k divisible by 6 meets this condition, taking i to be the largest power of 2 dividing k and j to be k / i; accordingly gives k = 6 as the first case it treats. BN curves and BLS curves, whose embedding degree is divisible by 6, are therefore affected by the exTNFS. The basic idea of the exTNFS is based on the equality GF(p^k) = GF((p^i)^j) and one of the improvements for reducing the amount of cost for solving FFDLP is using subfield calculation. Please refer to for detailed ideas and calculation algorithms of exTNFS. Due to exTNFS, the security levels of certain pairing-friendly curves asymptotically dropped down. For instance, Barbulescu and Duquesne estimated that the security of the BN curves, which had been believed to provide 128-bit security (BN256, for example) was reduced to approximately 100 bits . Here, the security levels described in this memo correspond to the security strength of NIST recommendation . There has since been research into the minimum bit length of the parameters of pairing-friendly curves for each security level when applying exTNFS as an attacking method for FFDLP. For 128-bit security, Barbulescu and Duquesne estimated the minimum bit length of p of BN curves and BLS12 curves after exTNFS as 461 bits . For 256-bit security, Kiyomura et al. estimated the minimum bit length of p^k of BLS48 curves as 27,410 bits, which indicated 572 bits of p .

Selection of Pairing-Friendly Curves In this section, we introduce some of the known secure pairing-friendly curves that consider the impact of exTNFS. First, we show the adoption status of pairing-friendly curves in standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", pairing-friendly curves corresponding to each security level are selected and their parameters are indicated. In our selection policy, it is important that selected curves are shown in peer-reviewed papers for security and that they are widely used in cryptographic libraries. In addition, "efficiency" is one of the important aspects but greatly dependent on implementations, so we choose to prioritize "security" and "widely used" over "efficiency" in consideration of future interconnections and interoperability over the internet. Within this policy, when "widely used" does not by itself distinguish between candidate curves at a given security level, we prefer the curve that provides security margin above the nominal security level: a margin advantage is a security consideration, and by the priority above it outranks an efficiency advantage of a lower-margin alternative. BLS12-381 is the one exception to this preference for margin: although its security level is estimated at approximately 126 bits , slightly below the nominal 128-bit target, it is retained because its adoption in production deployments (see ) decisively satisfies the "widely used" criterion. Where no candidate at a given security level satisfies "widely used", as is currently the case at the 256-bit level, this exception does not apply, and the preference for margin governs without qualification. As a result, we recommend the BLS curve with 381-bit characteristic of embedding degree 12 and the BN curve with the 462-bit characteristic for the 128-bit security level, and the BLS curves of embedding degree 48 with the 581-bit characteristic for the 256-bit security level. On the other hand, we do not show the parameters for 192-bit security here because there are no curves that match our selection policy.

Adoption Status of Pairing-Friendly Curves We show the pairing-friendly curves that have been selected by existing standards, cryptographic libraries, and applications. A comprehensive curve-by-curve comparison, including proposed alternatives that were not selected, is maintained at https://cfrg.github.io/draft-irtf-cfrg-pairing-friendly-curves/adoption-status.html. The adoption status of pairing-friendly curves is surveyed in standards, libraries and applications. The details are described as the following subsections. A BN curve with a XXX-bit characteristic p is denoted as BNXXX and a BLS curve of embedding degree k with a XXX-bit p is denoted as BLSk-XXX. Parameters whose security level is more than 5 bits below the 128-bit level are not candidates for selection here, because this document recommends against using parameters that fall that far below the 128-bit level. They are still named in the subsections below wherever a standard or a library supports them, and tabulates the adoption of the BN curves among them that are estimated at approximately 100 bits, which is useful information for implementers. The security level for each curve is evaluated in accordance with , , and . For the 128-bit level, revisits the Special variant of the tower number field sieve, which applies to pairing-friendly curves because their characteristic is a polynomial of moderate degree with tiny coefficients evaluated at a seed. It obtains lower cost estimates than an earlier estimate for all the families it examines except BLS12 and BN. Note that the Freeman curves and MNT curves are not included in this survey because does not show the security levels of these curves.

International Standards ISO/IEC 15946 series specifies public-key cryptographic techniques based on elliptic curves. The third edition of ISO/IEC 15946-5 (published 2022) reorganized the numerical examples and extended coverage to include BLS12, BLS24, and BLS48 curves. The BN462 parameter in this document matches the numerical example in Annex D.2.3 of exactly (chi = 2^114 + 2^101 - 2^14 - 1, written u there), and the BLS48-581 parameter matches Annex D.3.5 exactly (chi = -2^32 - 2^30 - 2^10 + 2^7 - 1). The same edition introduces a post-exTNFS security guideline that the characteristic p of BN and BLS12 curves should be at least 461 bits for the 128-bit security level. As described below, BN curves with 256-bit p and 512-bit p from earlier editions of ISO/IEC 15946-5 are referenced by other standards and libraries; these curves are denoted as BN256I and BN512I, where the suffix 'I' is given from the initials of the standard name ISO. TCG adopts the BN256I and a BN curve with 638-bit p specified by their own . FIDO Alliance and W3C adopt BN256I, BN512I, the BN638 by TCG, and the BN curve with 256-bit p proposed by Devegili et al. (named BN256D). The suffix 'D' of BN256D is given from the initials of the first author's name of the paper which proposed the parameter.

Cryptographic Libraries There are a lot of cryptographic libraries that support pairing calculations. is a high-performance pairing library maintained by Supranational. It supports BLS12-381 and is used in production by Ethereum consensus clients, Filecoin, and other applications. Several additional actively maintained libraries support BLS12-381. , developed by Consensys, supports BLS12-381, BN_SNARK1, BLS12-377, BLS24-315, and BW6-761. is a JavaScript/TypeScript library by Paul Miller supporting BLS12-381 and BN_SNARK1. The arkworks ecosystem provides Rust crates for pairing-friendly curves used in zero-knowledge proof systems, including BLS12-381 and BN_SNARK1. is a cryptographic library written in Nim that supports BLS12-381, BN254N, BN_SNARK1, BLS12-377, and BW6-761. is the Cloudflare Interoperable, Reusable Cryptographic Library and includes support for BLS12-381. is a collection of Rust crates for zero-knowledge cryptography supporting BLS12-381. These libraries name BN_SNARK1 after the size of its field, as bn254; calls the same curve alt_bn128. PBC is a library for pairing-based cryptography published by Stanford University that supports BN curves, MNT curves, Freeman curves, and supersingular curves . Users can generate pairing parameters by using PBC and use pairing operations with the generated parameters. is a library for pairing-based cryptography that supports four BN curves and BLS12-381. These BN curves include BN254 proposed by Nogami et al. (named BN254N), BN_SNARK1 suitable for SNARK applications , BN382M, and BN462. The suffix 'N' of BN254N and the suffix 'M' of BN382M are respectively given from the initials of the first author's name of the proposed paper and the library's name mcl. Kyushu University published a library that supports BLS48-581 . The University of Tsukuba Elliptic Curve and Pairing Library (TEPLA) supports two BN curves, BN254N and BN254 proposed by Beuchat et al. (named BN254B). The suffix 'B' of BN254B is given from the initials of the first author's name of the proposed paper. Intel published a cryptographic library named Intel Integrated Performance Primitives (Intel-IPP) and the library supports BN256I. uses various types of pairing-friendly curves including six BN curves (BN158, BN254N, BN256R, BN382R, BN446, and BN638), where BN256R and BN382R are RELIC specific parameters that are different from BN256I, BN256D, and BN382M. The suffix 'R' of BN256R and BN382R is given from the initials of the library's name RELIC. In addition, RELIC supports six BLS curves (BLS12-381, BLS12-446, BLS12-455, BLS12-638, BLS24-477, and BLS48-575 ), a Cocks-Pinch curve of embedding degree 8 with 544-bit p (named CP8-544) , pairing-friendly curves constructed by Scott et al. based on Kachisa-Scott-Schaefer curves with embedding degree 54 with 569-bit p (named K54-569) , a KSS curve of embedding degree 18 with 508-bit p (named KSS18-508) , Optimal TNFS-secure curve of embedding degree 8 with 511-bit p (OT8-511), and a supersingular curve with 1536-bit p (SS-1536). MIRACL Core (the successor to the Apache Milagro Crypto Library (AMCL) ) supports five BLS curves (BLS12-381, BLS12-461, BLS24-479, BLS48-556, and BLS48-581) and five BN curves (BN254N, BN254CX proposed by CertiVox, BN256I, BN512I, and BN462). Adjoint published a library that supports the BLS12-381 and six BN curves (BN_SNARK1, BN254B, BN254N, BN254S1, BN254S2, and BN462) , where BN254S1 and BN254S2 are BN curves adopted by an old version of AMCL . The suffix 'S' of BN254S1 and BN254S2 is given from the initials of the name of the developer who proposed these parameters. The Celo foundation published the bls12377js library . The supported curve is the BLS12-377 curve which is shown in .

Applications Zcash uses BN_SNARK1 in their library . In response to the exTNFS attacks, they proposed new parameters using the BLS12-381 curve and published its implementation . Ethereum adopted BLS12-381 for its consensus layer. The BLS12-381 precompile is also specified as an Ethereum precompile contract in EIP-2537 , enabling on-chain pairing operations. uses BLS12-381 via the blst library . Chia Network published their implementation , which uses the blst library . DFINITY uses mcl, and Algorand published an implementation whose virtual machine provides curve operations and a pairing check for BLS12-381 and for BN_SNARK1. The pairing check on BN_SNARK1 is also available on Ethereum, as the precompiled contract of .

For 128-bit Security The survey in shows a lot of cases of adopting BN and BLS curves. Among them, BLS12-381 and BN462 match our selection policy. In particular, the one that best matches the policy is BLS12-381 from the viewpoint of "widely used": as states, its adoption in production deployments is what makes it the one exception to the preference for margin. We therefore introduce the parameters of BLS12-381 in this memo. On the other hand, from the viewpoint of the future use, the parameter of BN462 is also introduced. As shown in recent security evaluations for BLS12-381 , its security level is close to 128 bits but less than 128 bits. If the attack is improved even a little, BLS12-381 will not be suitable for the curve of the 128-bit security level. As curves of 128-bit security level are currently the most widely used, we recommend both BLS12-381 and BN462 in this memo in order to have a more efficient and a more prudent option respectively.

BLS Curves for the 128-bit Security Level (BLS12-381) In this part, we introduce the parameters of the Barreto-Lynn-Scott curve of embedding degree 12 with 381-bit p that is adopted by a lot of applications such as Zcash , Ethereum , and so on. The BLS12-381 curve is shown in and it is defined by the parameter where chi is the parameter in and the size of p is 381 bits. For the finite field GF(p), the towers of extension field GF(p^2), GF(p^6) and GF(p^12) are defined by indeterminates u, v, and w as follows: Defined by chi, the elliptic curve E and its twist E' are represented by E: y^2 = x^3 + 4 and E': y^2 = x^3 + 4 * (u + 1). BLS12-381 is categorized as M-type. The untwist isomorphism psi of , restricted to E'(GF(p^2)), maps into E(GF(p^12)) and is given by where w^2 = v in GF(p^6) and v^3 = u + 1, per the tower given above. We have to note that the security level of this pairing is expected to be 126 rather than 128 bits . Parameters of BLS12-381 are given as follows.

• G_1 is the largest prime-order subgroup of E(GF(p))
  • BP = (x,y) : a 'base point', i.e., a generator of G_1
• G'_2 is the r-order subgroup of E'(GF(p^2)) corresponding to G_2 under psi
  • BP' = (x',y') : a 'base point', i.e., a generator of G'_2
    • x' = x'_0 + x'_1 * u (x'_0, x'_1 in GF(p))
    • y' = y'_0 + y'_1 * u (y'_0, y'_1 in GF(p))
  • h' : the cofactor #E'(GF(p^2))/r

p:

r:

x:

y:

h:

0x396c8c005555e1568c00aaab0000aaab

b:

4

x'_0:

x'_1:

y'_0:

y'_1:

h':

b':

4 * (u + 1)

As mentioned above, BLS12-381 is adopted in a lot of applications. Since it is expected that BLS12-381 will continue to be widely used, defines a normative point serialization format for it (with test vectors in ). This serialization format is also adopted in . In addition, many pairing-based cryptographic applications use a hash-to-curve procedure that outputs a rational point on an elliptic curve from an arbitrary input. specifies ciphersuites for hashing to an elliptic curve, including BLS12-381, and is valuable information for implementers.

BN Curves for the 128-bit Security Level (BN462) A BN curve with the 128-bit security level is shown in , which we call BN462. BN462 is defined by the parameter where chi is the parameter in and the size of p is 462 bits. For the finite field GF(p), the towers of extension field GF(p^2), GF(p^6) and GF(p^12) are defined by indeterminates u, v, and w as follows: Defined by chi, the elliptic curve E and its twist E' are represented by E: y^2 = x^3 + 5 and E': y^2 = x^3 - u + 2, respectively. The size of p becomes 462 bits. BN462 is categorized as D-type. The untwist isomorphism psi of , restricted to E'(GF(p^2)), maps into E(GF(p^12)) and is given by where w^2 = v in GF(p^6) and v^3 = u + 2, per the tower given above. We have to note that BN462 is significantly slower than BLS12-381, but has a 134-bit security level , so may be more resistant to future small improvements to the exTNFS attack. We note also that estimates an optimal ate pairing on CP8-544 to take about 20% less time than one on BN462, that CP8-544 has a 131-bit security level, and that describes it as the more conservative choice for users concerned about progress in variants of the number field sieve. However, as this curve is not widely used (it is only implemented in one library), we instead chose BN462 for our 'safe' option. We give the following parameters for BN462.

• G_1 is the largest prime-order subgroup of E(GF(p))
  • BP = (x,y) : a 'base point', i.e., a generator of G_1
• G'_2 is the r-order subgroup of E'(GF(p^2)) corresponding to G_2 under psi
  • BP' = (x',y') : a 'base point', i.e., a generator of G'_2
    • x' = x'_0 + x'_1 * u (x'_0, x'_1 in GF(p))
    • y' = y'_0 + y'_1 * u (y'_0, y'_1 in GF(p))
  • h' : the cofactor #E'(GF(p^2))/r

p:

r:

x:

y:

h:

1

b:

5

x'_0:

x'_1:

y'_0:

y'_1:

h':

b':

-u + 2

For 256-bit Security As shown in the survey in , there are three BLS48 candidates for 256-bit security: BLS48-556, BLS48-575 and BLS48-581. None of them is widely used in the sense of the policy given in , so the preference for margin governs. As noted in , puts the minimum size of p^k for BLS48 curves at 27,410 bits, which is 572 bits of p. BLS48-556 does not reach that size; BLS48-575 and BLS48-581 both exceed it, and BLS48-581 leaves the larger margin. We therefore select BLS48-581. The selected BLS48 curve is shown in and it is defined by the parameter where chi is the parameter in and the size of p is 581 bits. For the finite field GF(p), the towers of extension field GF(p^2), GF(p^4), GF(p^8), GF(p^24) and GF(p^48) are defined by indeterminates u, v, w, z, and s as follows: The elliptic curve E and its twist E' are represented by E: y^2 = x^3 + 1 and E': y^2 = x^3 - 1 / w. BLS48-581 is categorized as D-type. Concretely, in the tower above: w^2 = -v gives -1 / w = w / v, and v^2 = -(u + 1) gives w / v = w * v / v^2 = -w * v / (u + 1); since u^2 = -1, 1 / (u + 1) = (1 - u) / 2, so -1 / w = ((u - 1) / 2) * v * w. The untwist isomorphism psi of , restricted to E'(GF(p^8)), maps into E(GF(p^48)) and is given by where xi = u * s in GF(p^48) satisfies xi^6 = -w, the reciprocal of the twist coefficient b' = -1 / w, per the tower given above. Concretely: u in GF(p^2) satisfies u^2 = -1, so u^6 = -1; s in GF(p^48) satisfies s^2 = -z and z^3 = -w, so s^6 = w; hence xi^6 = u^6 * s^6 = (-1) * w = -w. We then give the parameters for BLS48-581 as follows.

• G_1 is the largest prime-order subgroup of E(GF(p))
  • BP = (x,y) : a 'base point', i.e., a generator of G_1
• G'_2 is the r-order subgroup of E'(GF(p^8)) corresponding to G_2 under psi
  • BP' = (x',y') : a 'base point', i.e., a generator of G'_2
    • x' = x'_0 + x'_1 * u + x'_2 * v + x'_3 * u * v + x'_4 * w + x'_5 * u * w + x'_6 * v * w + x'_7 * u * v * w (x'_0, ..., x'_7 in GF(p))
    • y' = y'_0 + y'_1 * u + y'_2 * v + y'_3 * u * v + y'_4 * w + y'_5 * u * w + y'_6 * v * w + y'_7 * u * v * w (y'_0, ..., y'_7 in GF(p))
  • h' : the cofactor #E'(GF(p^8))/r

p:

r:

x:

y:

x'_0:

x'_1:

x'_2:

x'_3:

x'_4:

x'_5:

x'_6:

x'_7:

y'_0:

y'_1:

y'_2:

y'_3:

y'_4:

y'_5:

y'_6:

y'_7:

h:

0x85555841aaaec4ac

b:

1

h':

b':

-1 / w

defines a normative point serialization format for BLS48-581 (with test vectors in ), extending the format defined by for BLS12-381 as specified in .

Serialization and Validation This section defines normative serialization and deserialization procedures for BLS12-381, and also extends them to BLS48-581. It also states what makes a deserialized value valid, and which of the remaining decisions belong to the calling protocol. What is encoded here are the objects that protocols transmit: points on E and on E', and scalars. Elements of GF(p) and of GF(p^m) appear as coordinates of those points rather than as objects with encodings of their own. Elements of G_T, which lie in GF(p^k), are not encoded here either: this document defines no byte encoding for them. Should a protocol come to require one, a separate specification can define it. The point format is based on the one originally defined by for BLS12-381 and is, in turn, based on the representation shown in with a small tweak to apply to GF(p^m). It is already relied upon, directly or indirectly, by and ; the latter extends it to BLS48-581, and the extension is adopted here. Applicability to BN462 is discussed in . At a high level, the point serialization format is defined as follows:

• Serialized points include three metadata bits that indicate whether a point is compressed or not, whether a point is the point at infinity or not, and (for compressed points) the sign of the point's y-coordinate.
• For a curve with characteristic p represented in n bytes, where n is the bit length of p divided by 8 and rounded up, points on E are serialized into n bytes (compressed) or 2n bytes (uncompressed). Points on E', represented over GF(p^m) for the m given in , where m = k/d for the twist degree d of , are serialized into m*n bytes (compressed) or 2*m*n bytes (uncompressed).
• The serialization of a point at infinity comprises a string of zero bytes, except that the metadata bits may be nonzero.
• The serialization of a compressed point other than the point at infinity comprises a serialized x-coordinate.
• The serialization of an uncompressed point other than the point at infinity comprises a serialized x-coordinate followed by a serialized y-coordinate.

Parameters and Notation

Curve	n (bytes)	E' field	m	Compressed (E / E')	Uncompressed (E / E')
BLS12-381	48	GF(p^2)	2	48 / 96 bytes	96 / 192 bytes
BLS48-581	73	GF(p^8)	8	73 / 584 bytes	146 / 1168 bytes

Below, we give detailed serialization and deserialization procedures, applicable to both curves using the parameters above. The following notation is used in the rest of this section:

• Elements of GF(p^m) are represented as a vector of m coefficients in GF(p), (y_0, ..., y_{m-1}), using the basis and coefficient ordering already defined for each curve in .
• The common procedures below use x and y for the coordinates of a nonidentity point on either E or E'. For points on E', x, y and their coefficients x_i, y_i use the same coordinate representation and coefficient ordering as x', y' and x'_i, y'_i in ; their values are those of the point being processed, not necessarily those of BP'.
• The identity element of G_1 is the point at infinity O_E of , and the identity element of G'_2 is the point at infinity on E'. Below, 'the point at infinity' refers to whichever of the two curves is in question.
• For a byte string str, str[0] is defined as the first byte of str.
• The function sign_GF_p(y) returns one bit representing the sign of an element y of GF(p), with y taken as an integer in the inclusive range [0, p - 1]. This function is defined as follows:

(p - 1) / 2, else { 0 otherwise. ]]>

• The function sign_GF_p^m(y), for an element y = (y_0, ..., y_{m-1}) of GF(p^m), returns one bit computed as follows: let i be the largest index in {0, ..., m-1} such that y_i is nonzero, or i = 0 if all coefficients are zero; return sign_GF_p(y_i). For BLS12-381 (m=2), this specializes to: sign_GF_p^2(y') = sign_GF_p(y'_0) if y'_1 equals 0, else sign_GF_p(y'_1). For BLS48-581 (m=8), this is the same function specified as sign_GF_p^8 in , evaluated over the coefficient ordering (y'_0, ..., y'_7) given in .
• The function OS2FE(str, n), for a byte string str of m*n bytes, returns an element of GF(p^m) or INVALID. It inverts the coordinate serialization of step 3 of : divide str into m consecutive blocks of n bytes each, and for each i in {0, ..., m-1} let y_i = OS2IP(str_i), where str_i is the block starting at offset (m - 1 - i) * n, so that the blocks give the coefficients in decreasing index order. If any y_i is greater than or equal to p, OS2FE returns INVALID; otherwise it returns y = (y_0, ..., y_{m-1}).

requires deciding whether a field element y2 is a square and, where it is, computing a square root. This document does not specify how. The following pointers are provided for implementers and are not requirements. For y2 in GF(p), all curves in this document have p = 3 (mod 4). Section 4 and Appendix I.1 of therefore apply directly: y2 is a square exactly when y2^((p-1)/2) is 0 or 1, and a square root is given by y2^((p+1)/4). For y2 in GF(p^m), that shortcut does not apply, since p^2 and p^8 are both 1 (mod 4). For BN462 and BLS12-381, p^2 = 9 (mod 16), so Appendix I.3 of applies to GF(p^2). Appendix I.4 of gives a constant-time Tonelli-Shanks procedure for a general field, and Appendix I.5 gives an is_square test for GF(p^2). A faster approach reduces a square root in GF(p^2) to square roots in GF(p) by way of the norm , and the exponentiations in GF(p) that it needs can be shared with the is_square test . Since GF(p^8) is built as a tower of quadratic extensions, the same reduction applies one level at a time for BLS48-581 . Implementations such as , , , and compute square roots in GF(p^2) in this way.

Scalar Serialization This section defines a serialization format for elements of the scalar field GF(r), where r is the order of G_1 and G_2 as given for each curve in . Unlike point serialization, this format applies to all three curves in this document (BLS12-381, BN462, and BLS48-581), since no metadata bits are required. For a curve with scalar field order r represented in n_s bytes, where n_s is the bit length of r divided by 8 and rounded up:

Curve	n_s (bytes)
BLS12-381	32
BN462	58
BLS48-581	65

Serialization: a scalar kappa in the range [0, r - 1] is serialized as I2OSP(kappa, n_s). Deserialization: given a byte string s_string of length n_s, let kappa = OS2IP(s_string). If kappa >= r, return INVALID. Otherwise, return kappa. Rejecting values greater than or equal to r gives every scalar exactly one encoding, which matters wherever an encoded scalar is hashed or compared as bytes. The byte order is the big-endian order of I2OSP and OS2IP , which is the order used by and . Other specifications encode scalars in little-endian order, among them, so an implementation working with both needs to convert. This document does not define a distinct encoding for the zero scalar. Whether a protocol accepts it is a protocol-level decision, discussed in .

Point Serialization This section defines point_to_octets_G1 and point_to_octets_G2. point_to_octets_G1 takes an element of G_1, which is a point on E, and point_to_octets_G2 takes an element of G'_2, which is a point on E'; each returns a byte string. Both are given by the single procedure below, stated for a point P, written P = (x, y) when P is not the point at infinity, and the parameters n and m of . This procedure uses the I2OSP function defined in .

1. Compute the metadata bits C_bit, I_bit, and S_bit, as follows:
   • C_bit is 1 if point compression should be used, otherwise it is 0.
   • I_bit is 1 if P is the point at infinity, otherwise it is 0.
   • S_bit is 0 if P is the point at infinity or if point compression is not used. Otherwise (i.e., when point compression is used and P is not the point at infinity), if P is a point on E, S_bit = sign_GF_p(y), else if P is a point on E', S_bit = sign_GF_p^m(y).
2. Let m_byte = (C_bit * 2^7) + (I_bit * 2^6) + (S_bit * 2^5).
3. Let x_string be the serialization of x, which is defined as follows:
   • If P is the point at infinity on E, let x_string = I2OSP(0, n).
   • If P is a point on E other than the point at infinity, then x is an element of GF(p), i.e., an integer in the inclusive range [0, p - 1]. In this case, let x_string = I2OSP(x, n).
   • If P is the point at infinity on E', let x_string = I2OSP(0, m*n).
   • If P is a point on E' other than the point at infinity, then x can be represented as (x_0, ..., x_{m-1}) where each x_i is an element of GF(p). In this case, let x_string = I2OSP(x_{m-1}, n) concatenated with I2OSP(x_{m-2}, n), ..., concatenated with I2OSP(x_0, n) (i.e., coefficients in decreasing index order). Notice that in all of the above cases, the 3 most significant bits of x_string[0] are guaranteed to be 0.
4. If point compression is used, let y_string be the empty string. Otherwise (i.e., when point compression is not used), let y_string be the serialization of y, which is defined in step 3.
5. Let s_string be the concatenation of x_string and y_string.
6. Set s_string[0] = x_string[0] OR m_byte, where OR is computed bitwise. After this operation, the most significant bit of s_string[0] equals C_bit, the next bit equals I_bit, and the next equals S_bit. (This is true because the three most significant bits of x_string[0] are guaranteed to be zero, as discussed above.)
7. Return s_string.

Point Deserialization This section defines octets_to_point_G1 and octets_to_point_G2. Each takes a byte string and returns an element of G_1 or of G'_2 respectively, or INVALID. A string that deserializes to a point of E or E' that is not in the group is INVALID, so a value returned by these procedures is a group element and a caller does not have to obtain one by a further step. This document does not define a deserialization procedure that stops at E or E'. G_1 and G_2 are the groups on which the pairing of is defined, and elements of G_1 and of G'_2 are what the specifications citing this document exchange; psi carries an element of G'_2 to the corresponding element of G_2, on which the pairing operates, as described in . Section 5.3 of requires conforming implementations to perform the subgroup check for the same reason, and Section 6.3 of notes that a library may combine the two operations. The procedure below is stated once, for a string s_string and the parameters n and m of . It uses the OS2IP function defined in and the OS2FE function defined in . Each of the two functions fixes the group it returns, and the curve that step 2 determines is what selects between them. octets_to_point_G1 MUST return INVALID if step 2 determines E', and octets_to_point_G2 MUST return INVALID if step 2 determines E. This check is not redundant: the encodings of the two groups can have the same length. For BLS12-381, for instance, a 96-byte string is a compressed point on E' when C_bit is 1 and an uncompressed point on E when C_bit is 0, so without this rule a compressed element of G'_2 passed to octets_to_point_G1 would be decoded and returned rather than rejected. Every GF(p) coefficient recovered by this procedure MUST be an integer in the inclusive range [0, p - 1]. A byte string that encodes a coordinate, or a coefficient of a coordinate, as a value greater than or equal to p is not a canonical encoding of a field element; implementations MUST return INVALID in that case. This applies to coordinates on E, recovered with OS2IP, as well as to the coefficients of coordinates on E', recovered with OS2FE.

1. If s_string is empty, return INVALID. Otherwise, let m_byte = s_string[0] AND 0xE0, where AND is computed bitwise. In other words, the three most significant bits of m_byte equal the three most significant bits of s_string[0], and the remaining bits are 0. If m_byte equals any of 0x20, 0x60, or 0xE0, return INVALID. Otherwise:
   • Let C_bit equal the most significant bit of m_byte,
   • Let I_bit equal the second most significant bit of m_byte, and
   • Let S_bit equal the third most significant bit of m_byte.
2. If C_bit is 1:
   • If s_string has length n bytes, the output point is on the curve E.
   • If s_string has length m*n bytes, the output point is on the curve E'.
   • If s_string has any other length, return INVALID.
   If C_bit is 0:
   • If s_string has length 2n bytes, the output point is on E.
   • If s_string has length 2*m*n bytes, the output point is on E'.
   • If s_string has any other length, return INVALID.
3. Let s_string[0] = s_string[0] AND 0x1F, where AND is computed bitwise. In other words, set the three most significant bits of s_string[0] to 0.
4. If I_bit is 1:
   • If s_string is not the all zeros string, return INVALID.
   • Otherwise (i.e., if s_string is the all zeros string), return the identity element of the group determined in step 2.
   Otherwise, I_bit is 0. Continue.
5. If C_bit is 0:
   • Let x_string be the first half of s_string.
   • Let y_string be the last half of s_string.
   • If the curve that was determined in step 2 is E:
     • Let x = OS2IP(x_string). If x is greater than or equal to p, return INVALID.
     • Let y = OS2IP(y_string). If y is greater than or equal to p, return INVALID.
     • If the point P = (x, y) is not a valid point on E, return INVALID.
   • Otherwise (i.e., when the curve that was determined in step 2 is E'):
     • Let x = OS2FE(x_string, n). If x is INVALID, return INVALID.
     • Let y = OS2FE(y_string, n). If y is INVALID, return INVALID.
     • If the point P = (x, y) is not a valid point on E', return INVALID.
   Let P = (x, y) and continue at step 8. Otherwise, C_bit is 1. Continue.
6. Let x_string be s_string.
   • If the curve that was determined in step 2 is E:
     • Let x = OS2IP(x_string). If x is greater than or equal to p, return INVALID.
     • Let y2 = the right-hand side of the curve equation for E (given in for the curve in question), evaluated at x, in GF(p).
     • If y2 is not square in GF(p), return INVALID.
     • Otherwise, let y = sqrt(y2) in GF(p) and let Y_bit = sign_GF_p(y).
   • Otherwise (i.e., when the curve that was determined in step 2 is E'):
     • Let x = OS2FE(x_string, n). If x is INVALID, return INVALID.
     • Let y2 = the right-hand side of the curve equation for E' (given in for the curve in question), evaluated at x, in GF(p^m).
     • If y2 is not square in GF(p^m), return INVALID.
     • Otherwise, let y = sqrt(y2) in GF(p^m) and let Y_bit = sign_GF_p^m(y).
7. If S_bit equals Y_bit, let P = (x, y). Otherwise, let P = (x, -y).
8. If the curve determined in step 2 is E and subgroup_check_G1(P) returns FALSE, return INVALID. If the curve determined in step 2 is E' and subgroup_check_G2(P) returns FALSE, return INVALID. Otherwise, return P.

Note that OS2FE outputs field elements in the towered representation of the curve in question:

• For BLS12-381, OS2FE(x_string, n) = (x'_0, x'_1) = x'_0 + x'_1 * u
• For BLS48-581, OS2FE(x_string, n) = (x'_0, ..., x'_7) = x'_0 + x'_1 * u + x'_2 * v + x'_3 * u * v + x'_4 * w + x'_5 * u * w + x'_6 * v * w + x'_7 * u * v * w

Subgroup Membership subgroup_check_G1(P) takes a point P on E and returns TRUE if P is an element of G_1 and FALSE otherwise. subgroup_check_G2(Q) does the same for a point Q on E' and the group G'_2. Both are used by , and both are specified here as operations in their own right, because a point can also arise from point addition or scalar multiplication rather than from a byte string, and a caller may need to check such a point. For every curve in this document, r^2 divides neither the order of E(GF(p)) nor the order of E'(GF(p^m)): those orders are h * r and h' * r, and gcd(h, r) = gcd(h', r) = 1 by the definitions of h and h' in . Consequently a point of order dividing r is an element of G_1, or of G'_2, respectively, and both checks can be carried out as follows:

• subgroup_check_G1(P) returns TRUE if [r]P is the point at infinity on E, and FALSE otherwise.
• subgroup_check_G2(Q) returns TRUE if [r]Q is the point at infinity on E', and FALSE otherwise.

Faster tests are known for particular curves. Any method that decides the same predicate may be used. These checks apply to all three curves in this document. Note that for BN462 the cofactor h of E(GF(p)) is 1, so every point of E(GF(p)) is an element of G_1 and subgroup_check_G1 always returns TRUE; the cofactor h' of E'(GF(p^2)) is not 1, so subgroup_check_G2 remains meaningful.

Applicability to BN462 This document does not specify a point encoding for BN462. Scalar serialization, defined in , and the subgroup checks of are unaffected and apply to BN462 as well. The coordinate encoding of (coordinates as fixed-length big-endian integers, with the coefficients of an element of GF(p^m) in decreasing index order) carries over to BN462 unchanged. What does not fit is the placement of the metadata bits. BN462 has a 462-bit characteristic p, so its canonical GF(p) representation occupies n = ceil(462 / 8) = 58 bytes, that is 464 bits. This leaves 2 unused bits in the leading byte of a serialized coordinate, one short of the three (C_bit, I_bit, S_bit) that the scheme above places there. describes two ways of accommodating that: carrying the metadata in a byte of its own, following the general pattern of , which leaves the rest of the format unchanged; or restricting the format to uncompressed points, which need only C_bit and I_bit and therefore fit in the two bits available. This document specifies neither. The format above is specified here because it is already widely used in applications, and because specifications depend on it: it originates with and is relied upon by and . For BN462 neither consideration holds: no specification examined requires a BN462 point encoding, and the implementations that do emit BN462 points have not converged on one of the variants above. Choosing among them would therefore be encoding design rather than the recording of established practice, and this document restates an encoding only where practice has already settled on one. Implementations that nevertheless need to exchange BN462 points may find useful. It records, informatively, the encodings that existing implementations use and the alternatives that have been considered. It defines no format.

Requirements on Calling Protocols The procedures above leave three decisions to the protocol that uses them. This document does not decide them, because the right answer depends on what the protocol does rather than on the curve or the wire format. A specification that adopts this format SHOULD state its answer to each.

Accepted Point Form Both a compressed and an uncompressed form are defined. The compressed form is RECOMMENDED for values that are transmitted: it is the form places on the wire, and the form used by , and . The uncompressed form is retained because it remains in use for stored values, such as verification keys that are validated once, where recovering y from x on every use is not worth the saved space. A protocol SHOULD state which forms it accepts. Within one form, each point has exactly one encoding, since rejects non-canonical coordinates and unused combinations of the metadata bits. Accepting both forms means that one point has two encodings, which matters wherever an encoded point is hashed or compared as a byte string: a value that contains a point, such as a signature or a proof, can be re-encoded in the other form and still be accepted, while its bytes and its hash change. A protocol that hashes an encoded point, or compares encoded points as byte strings, SHOULD accept exactly one form for that value.

Identity Element and define a byte representation for the identity element of G_1 and of G'_2, via the I_bit, and deserialization returns it as it does any other group element. Whether a calling protocol should accept it depends on that protocol's own semantics and threat model, not on the wire format: some protocols (e.g., certain zero-knowledge proof constructions) legitimately reference the identity element as part of a public statement, while for others it cannot arise in normal operation. Because both kinds of protocol exist, this document does not name one of them as what happens when a protocol says nothing. It defines the two behaviors, and a protocol using this document's serialization format SHOULD state which one it requires:

• Reject identity: after running , if the resulting point is the identity element, treat the overall result as INVALID. This is the appropriate choice for protocols where the identity element is not an expected input in normal operation.
• Allow identity: use the result of as-is, including when it is the identity element. This is appropriate for protocols with a specific, documented need to represent the identity element.

Neither behavior is part of itself, which returns the identity element as it returns any other group element. Rejecting it is a step the calling protocol takes on the result. Section 5.2 of is an example of the first choice, and gives a protocol-level reason for it: the secret key corresponding to an identity public key is zero, and under such a key the identity element is a valid signature on every message.

Zero Scalar accepts the zero scalar, and a protocol using it SHOULD state whether it does the same. This is a separate decision from the one above. rejects the identity element when deserializing a group element (Section 3.1) while accepting zero scalars (Section 6), so the two choices are made independently in at least one existing specification.

Security Considerations The recommended pairing-friendly curves are selected by considering the exTNFS proposed by Kim and Barbulescu in 2016 and they are categorized in each security level in accordance with and , apart from BLS12-381, whose case is described below. Implementers who will newly develop pairing-based cryptography applications SHOULD use the recommended parameters. The estimates cited here (, , , ) were reviewed against the work published in the major peer-reviewed cryptography venues, and in the IACR Cryptology ePrint Archive, between January 2020 and August 2026; records what that review covered. The work that review covered stays within the number field sieve and its tower variants rather than introducing a different kind of attack: it consists of record discrete-logarithm computations, refinements of the asymptotic analysis, and improvements to individual steps of the tower variant for fields of the extension degrees these curves use. is an example of the last kind: for the Conjugation method of polynomial selection, it accelerates the linear algebra step over GF(p^12), the field that BLS12-381 and BN462 use, by a factor of approximately 144. None of that work gives a bit-level security estimate for the curves recommended here that is lower than those this document cites, and this document has not derived estimates of its own. Work published after August 2026 is not covered, and has to be assessed separately. estimated that BLS curves of embedding degree 12 require a characteristic p of 461 bits or larger to achieve the 128-bit security level. Note that the security level of BLS12-381, which is adopted by a lot of libraries and applications, is slightly below 128 bits: its 381-bit characteristic is below that size, and its security level is estimated at approximately 126 bits . BN254 is used in most of the existing implementations as shown in and ; however, BN curves that were regarded as providing 128-bit security before exTNFS, including BN254, are estimated at approximately 100 bits after exTNFS . The following points also apply to implementations of pairing-based cryptographic applications that use the recommended curves. Regarding the use cases of pairing-based cryptography, please refer to . In applications such as key agreement protocols, users exchange elements of G_1 and of G'_2 as public keys. What such an exchange has to establish is that a received point belongs to the intended prime-order subgroup. A point obtained from a byte string through already satisfies this, since those procedures return an element of G_1 or of G'_2 or nothing at all. Group operations preserve the property: a sum or a scalar multiple of elements of G_1 is again an element of G_1, and likewise for G'_2, so a point computed from checked inputs does not need checking again. What does need checking is a point whose provenance does not establish membership, such as one built from coordinates supplied by another party or one whose group is no longer tracked by the implementation. Before such a point is used as an argument to the pairing, the implementation MUST establish that it belongs to the corresponding subgroup. This is a condition on the domain of the map rather than a defensive measure: the pairing of is defined on the r-torsion points, and a point outside the subgroup is not an admissible argument. Applying the checks of , or any other method deciding the same predicate, satisfies this requirement. Membership in the subgroup does not on its own exclude the identity element, which accepts; whether a protocol accepts it is the separate decision described in . Note also that subgroup security in the sense of is a property of a curve rather than of a point: it constrains the prime factors of the cofactors of the pairing groups. It is therefore a criterion applied when curves are selected, and not a check an implementation performs on a received value. The pairing-based protocols, such as the BLS signatures, use a scalar multiplication in G_1, G'_2 and an exponentiation in G_T with the secret key. In order to prevent the leakage of the secret key due to side channel attacks, implementers SHOULD apply countermeasure techniques such as the Montgomery ladder when they implement modules of a scalar multiplication and an exponentiation. Please refer to and for the detailed algorithms of the Montgomery ladder. A coordinate that is read from a byte string has to be checked against the order of the field it is claimed to lie in ; a coefficient outside that range gives one value several encodings, which can lead to vulnerabilities such as signature forgery. makes this requirement normative for the procedures defined in this document. The choice between the two identity-element behaviors described in belongs to the calling protocol, because whether the identity element can legitimately appear is a property of the protocol rather than of the curve or the wire format. Treating the identity element as an unremarkable, always-valid deserialization result, when the calling protocol does not actually expect it, can introduce timing side channels from identity-checking branches. Protocol specifications SHOULD state explicitly whether they require the identity-rejecting or identity-allowing behavior, consistent with their own security assumptions, and SHOULD do the same for the zero scalar (). Recommended parameters are affected by Cheon's attack which is a solving algorithm for the strong DH problem . The mathematical problem that provides the security of the strong DH problem is called ECDLP with Auxiliary Inputs (ECDLPwAI). In ECDLPwAI, the rational points P and [K^i]P for i = 1, ..., delta are given, and the task is to find the secret K. For a divisor delta of r - 1, Cheon's algorithm recovers K in O(log r * (sqrt(r / delta) + sqrt(delta))) group operations , whereas solving ECDLP by a generic method takes O(sqrt(r)) group operations, so for a well chosen delta the work of ECDLPwAI becomes dramatically smaller than that of ECDLP. A second variant applies when delta divides r + 1 rather than r - 1, and has a different complexity. Please refer to for the details of both. The design of a cryptographic protocol based on the strong DH problem therefore has to take this attack into account. For example, in the case of Short Signatures, the attack can be prevented by carefully setting the maximum number of queries, which corresponds to the parameter delta.

IANA Considerations This document has no IANA actions.

Acknowledgements Tsunekazu Saito was a co-author of this document from its first version through revision 11, and much of what it contains comes from that work. The authors would like to thank a lot of authors including Akihiro Kato for their significant contribution to early versions of this memo. The authors would also like to acknowledge Taechan Kim, Hoeteck Wee, Sergey Gorbunov, Michael Scott, Chloe Martindale as an Expert Reviewer, Watson Ladd, Armando Faz, Rene Struik, and Diego F. Aranha for their valuable comments. The authors would further like to thank Thomas Bellebaum, Frank Denis, Emil Lundberg, Michele Orrù, and Mamy Ratsimbazafy for their detailed reviews of recent revisions, which shaped Section 5 in particular.

References Normative References National Institute of Standards and Technology (NIST) Informative References The Celo Foundation 3GPP ISO/IEC Trusted Computing Group (TCG) Google Google Google Mozilla Microsoft Microsoft Microsoft Nok Nok Labs Yubico Intel Corporation Zcash Chia Network n.d. Standards for Efficient Cryptography Group (SECG) ECRYPT ISO/IEC MIRACL Ltd. SCIPR Lab zkcrypto zkcrypto Cloudflare University of Tsukuba The Apache Software Foundation Intel Corporation Kyushu University Adjoint Inc. The Apache Software Foundation Supranational LLC Consensys Software Inc. arkworks contributors JC-Lab Protocol Labs Algorand

Computing the Optimal Ate Pairing Before presenting the computation of the optimal ate pairing e(P, Q) satisfying the properties shown in , we give the subfunctions used for the pairing computation. The following algorithm, Line_function, shows the computation of the line function. It takes nonidentity points A = (x_A, y_A), B = (x_B, y_B) in G_2, and a nonidentity point P = (x, y) in G_1 as input, and outputs an element of GF(p^k). When implementing the line function, the isomorphism of E and its twist curve E' can be used to reduce the computational cost of operations in G_2 . We note that Line_function does not consider such an isomorphism; i.e., the above pseudocode operates on coordinates in untwisted form.

Optimal Ate Pairings over Barreto-Naehrig Curves Let c = 6 * chi + 2 for a parameter chi and c_0, c_1, ..., c_N in {-1,0,1} with c_N != 0 such that the sum of c_i * 2^i (i = 0, 1, ..., N) equals c. Implementations such as and compute c from chi and choose c_0, c_1, ..., c_N with few nonzero digits, taking advantage of the low Hamming weight of chi. The computation of the optimal ate pairing uses the p-power Frobenius endomorphism pi of , applied to Q = (x_Q, y_Q) in G_2, that is, to a point on E(GF(p^k)) in untwisted form. The pseudocode below writes it with the characteristic as an explicit argument, pi(p, Q) = (x_Q^p, y_Q^p). The following algorithm shows the computation of the optimal ate pairing on BN curves. It takes P in G_1, Q in G_2, an integer c, c_0, ..., c_N in {-1,0,1} with c_N != 0 such that the sum of c_i * 2^i (i = 0, 1, ..., N) equals c, and the order r of G_1 as input, and outputs e(P, Q). If P or Q is the point at infinity O_E, the output is 1, as required by .

Optimal Ate Pairings over Barreto-Lynn-Scott Curves Let c = chi for a parameter chi and c_0, c_1, ..., c_N in {-1,0,1} with c_N != 0 such that the sum of c_i * 2^i (i = 0, 1, ..., N) equals c. The following algorithm shows the computation of the optimal ate pairing on Barreto-Lynn-Scott curves. It takes P in G_1, Q in G_2, an integer c, c_0, ..., c_N in {-1,0,1} with c_N != 0 such that the sum of c_i * 2^i (i = 0, 1, ..., N) equals c, and the order r of G_1 as input, and outputs e(P, Q). If P or Q is the point at infinity O_E, the output is 1, as required by .

Implementation Notes This appendix is informative. It documents implementation considerations discovered through verification of this memo's pseudocode against widely used pairing libraries (mcl, noble-curves, blst), and does not standardize any algorithm.

Cofactors in Existing Libraries Some implementations evaluate a fixed multiple of the final exponent. Their output differs from the literal output of the pseudocode in by a curve-specific exponent in G_T: where alpha is:

• BLS12-381: alpha = 3
• BN462: alpha = 2 * chi * (6 * chi^2 + 3 * chi + 1) mod r
• BLS48-581: alpha = 3

Because gcd(alpha, r) = 1 for all three curves, the following properties hold:

• Bilinearity is preserved: e_lib([K]P, [L]Q) = e_lib(P, Q)^{K * L}.
• Verification equations of the form e(A, B) = e(C, D) hold using e_lib if and only if they hold using e_pseudocode.
• Direct byte-comparison between e_lib output and the test vectors in will not match. Implementations seeking byte-level reproducibility of those test vectors should evaluate the pseudocode in literally, without applying the cofactor optimization.

Final Exponentiation Decomposition The pseudocode in writes the final exponentiation as a single step, f := f^((p^k - 1) / r). In practice, implementations compute this via an easy/hard split: an easy part computed cheaply via the Frobenius endomorphism, and a hard part computed via an addition chain over the curve parameter chi. Standard references for the hard-part addition chain include (the original approach for BLS curves) and (for BN curves). and are cited in for a different reason: each evaluates a fixed multiple of the hard part rather than the hard part itself, which is where the exponent alpha given there comes from.

Test Vectors of Optimal Ate Pairing We provide test vectors for the optimal ate pairing e(P, Q) given in for the curves BLS12-381, BN462 and BLS48-581 given in . Here, the inputs are P = BP = (x, y) and Q = psi(BP'), where BP and BP' = (x', y') are the base points given in . Note: The G_2 input is given in this appendix by the base point BP' = (x', y') in twisted form, that is, as the corresponding point of G'_2, with coordinates in GF(p^(k/d)), which gives a compact representation. The pseudocode in operates on points of the untwisted curve E(GF(p^k)). An implementation invoking that pseudocode directly has to apply the untwist isomorphism psi of , whose formula for each curve is given in , to BP' first, to obtain Q on E(GF(p^k)). Most existing libraries perform this lifting implicitly by using twisted-form variants of Line_function, which are mathematically equivalent and more efficient. For BLS12-381 and BN462, BP' = (x', y') is given by where u is an indeterminate and x'_0, x'_1, y'_0, y'_1 are elements of GF(p). For BLS48-581, BP' = (x', y') is given by where u, v and w are indeterminates and x'_0, ..., x'_7 and y'_0, ..., y'_7 are elements of GF(p). In addition, we use the notation e_i (i = 0, ..., k-1) for the coefficients of e(P, Q) over GF(p), with respect to the tower of extension fields defined for each curve in . The basis is the set of products of powers of the indeterminates of that tower, indexed so that each indeterminate contributes a stride equal to the degree over GF(p) of the field it extends. For BLS12-381 and BN462 (k = 12), with the towers of and , this gives For BLS48-581 (k = 48), with the tower of , the same rule gives the 48 basis elements u^i1 * v^i2 * w^i3 * z^i4 * s^i5, where i1, i2, i3 and i5 are in {0, 1} and i4 is in {0, 1, 2}. The coefficient of that basis element is e_i with BLS12-381:

Input x value:

Input y value:

Input x'_0 value:

Input x'_1 value:

Input y'_0 value:

Input y'_1 value:

e_0:

e_1:

e_2:

e_3:

e_4:

e_5:

e_6:

e_7:

e_8:

e_9:

e_10:

e_11:

BN462:

Input x value:

Input y value:

Input x'_0 value:

Input x'_1 value:

Input y'_0 value:

Input y'_1 value:

e_0:

e_1:

e_2:

e_3:

e_4:

e_5:

e_6:

e_7:

e_8:

e_9:

e_10:

e_11:

BLS48-581:

Input x value:

Input y value:

Input x'_0 value:

Input x'_1 value:

Input x'_2 value:

Input x'_3 value:

Input x'_4 value:

Input x'_5 value:

Input x'_6 value:

Input x'_7 value:

Input y'_0 value:

Input y'_1 value:

Input y'_2 value:

Input y'_3 value:

Input y'_4 value:

Input y'_5 value:

Input y'_6 value:

Input y'_7 value:

e_0:

e_1:

e_2:

e_3:

e_4:

e_5:

e_6:

e_7:

e_8:

e_9:

e_10:

e_11:

e_12:

e_13:

e_14:

e_15:

e_16:

e_17:

e_18:

e_19:

e_20:

e_21:

e_22:

e_23:

e_24:

e_25:

e_26:

e_27:

e_28:

e_29:

e_30:

e_31:

e_32:

e_33:

e_34:

e_35:

e_36:

e_37:

e_38:

e_39:

e_40:

e_41:

e_42:

e_43:

e_44:

e_45:

e_46:

e_47:

Test Vectors for Serialization This appendix gives test vectors for the serialization procedures defined in . The point vectors are computed for the base points BP and BP' given in , in the compressed form (C_bit = 1) and in the uncompressed form (C_bit = 0). The scalar vectors are given for all three curves, since applies to BN462 as well. In each uncompressed string, the first half is the corresponding compressed string with the three metadata bits cleared, and the second half is the y-coordinate laid out by the rule of step 3 of . Hex strings are broken at a whole number of bytes.

BLS12-381 Points G_1 (BP), compressed (48 bytes): G_1 (BP), uncompressed (96 bytes): G'_2 (BP'), compressed (96 bytes): G'_2 (BP'), uncompressed (192 bytes): Identity on E: 48 zero bytes with the leading byte set to 0xc0 (C_bit = 1, I_bit = 1) when compressed, and 96 zero bytes with the leading byte set to 0x40 (I_bit = 1) when uncompressed. Identity on E': 96 zero bytes with the leading byte set to 0xc0 when compressed, and 192 zero bytes with the leading byte set to 0x40 when uncompressed.

• Note: the point values above are the second entry of each of the valid test vector files distributed with , whose first entry is the identity; they have been compared byte for byte. The uncompressed values are derived from the same coordinates by the procedure of , and have been checked to deserialize back to those coordinates. The same strings have also been checked against and : each deserializes to the coordinates given in and serializes back to the same bytes. The BLS12-381 scalars of were checked against the same two implementations.

BLS48-581 Points G_1 (BP), compressed (73 bytes): G_1 (BP), uncompressed (146 bytes): G'_2 (BP'), compressed (584 bytes): G'_2 (BP'), uncompressed (1168 bytes): Identity on E: 73 zero bytes with the leading byte set to 0xc0 (C_bit = 1, I_bit = 1) when compressed, and 146 zero bytes with the leading byte set to 0x40 (I_bit = 1) when uncompressed. Identity on E': 584 zero bytes with the leading byte set to 0xc0 when compressed, and 1168 zero bytes with the leading byte set to 0x40 when uncompressed.

• Note: the point values above are newly computed for this document by applying the sign_GF_p^8 function of to the BP' coordinates in .

Scalars The values below are the boundary cases of : the zero scalar, the smallest nonzero scalar, the largest scalar the procedure accepts, and the smallest value it rejects. The value kappa = 1 distinguishes the byte order, and kappa = r exercises the rejection of values that are not less than r. BLS12-381 (n_s = 32): BN462 (n_s = 58): BLS48-581 (n_s = 65):

Point Serialization for BN462 This appendix is informative. It records why the metadata placement of does not fit BN462, which encodings existing BN462 implementations use, and which variants were considered and set aside. It defines no format, standardizes no algorithm, and places no requirement on implementations. Its purpose is to spare implementers of BN462 the effort of rediscovering the constraint described below, and to record the state of practice at the time of writing. The observations below were obtained by reading the source code of the cited libraries in August 2026. They describe what those libraries emit and accept; no survey of deployed protocols or products was carried out.

The Constraint The format of carries three metadata bits (C_bit, I_bit, S_bit) in the three most significant bits of the first byte of a serialized coordinate. This requires the canonical representation of an element of GF(p) to leave at least three unused bits in its leading byte. BN462 has a 462-bit characteristic p, so n = ceil(462 / 8) = 58 bytes, i.e. 464 bits, and only 464 - 462 = 2 bits are unused: one bit short, as stated in . The same criterion appears in implementations. selects between two point encodings at compile time using the condition (MBITS - 1) mod 8 <= 4, where MBITS is the bit length of p; this condition holds exactly when the leading byte of a coordinate has three or more unused bits. When it holds, the library packs a compression flag (0x80) and a sign flag (0x20) into that byte, reserving 0x40; when it does not, it falls back to the encoding described in . For BN462, (462 - 1) mod 8 = 5, so the fallback is used. The diagnosis above is therefore not particular to this document: an implementation supporting BN462 reaches the same conclusion by the same test. (The bit-packing path is additionally gated on a build-time option that the shipped configuration does not enable, so the default build uses the fallback encoding for every curve it supports.)

Encodings Used by Existing Implementations Few libraries implement BN462 at all. Among those surveyed for this document, it is absent from , , , and , each of which does implement BLS12-381. The following do provide it:

Implementation	G_1 size	Metadata placement	Byte order
	117 / 59 bytes	type byte	big-endian
	117 / 59 bytes	type byte	big-endian
	117 / 59 bytes	dedicated flag byte	big-endian
	116 / 58 bytes	none / packed into the coordinate	little-endian

Sizes are given as uncompressed / compressed, for G_1. For and , the corresponding G'_2 sizes are 233 bytes uncompressed and 117 bytes compressed. The type byte is 0x04 for an uncompressed point and 0x02 or 0x03 for a compressed one; the dedicated flag byte is described in . The byte order given for is its default. Both leading-byte forms leave the coordinate encoding of untouched: writes the coefficients of a GF(p^2) coordinate in decreasing index order, as that section does, and so does . The two differ only in what the leading byte means. Note that itself defines point encoding over prime fields and binary extension fields only, so its type byte applied to E'(GF(p^2)) is an extension of it by the coefficient rule of rather than as written. In , BN462 is marked deprecated. Its affine serialization writes x followed by y with no metadata at all, its compressed form stores the parity of y in the most significant bit of the most significant byte of the coordinate, and the identity element is represented by an all-zero string. likewise has no distinct representation for the identity element: it emits the ordinary type byte followed by zero coordinates, and its decoding routine reports a failure for such a string. This differs from the approach of , which represents the identity element explicitly through I_bit and leaves the decision of whether to accept it to the calling protocol (). Two observations follow. First, the implementations that support BN462 and do not mark it deprecated have converged on a dedicated leading byte rather than on packing metadata into the coordinate; , which does mark it deprecated, is the exception and packs the parity of y into the coordinate. Second, none of the implementations examined carries the pair C_bit and I_bit in the two spare bits of the coordinate, which is the arrangement considers.

Alternative Considered: Two Metadata Bits S_bit is meaningful only for compressed points (see step 1 of ). An encoding restricted to uncompressed points therefore needs only C_bit and I_bit, which fit in the two spare bits that BN462 does have. The appeal of such an encoding is that BN462 would remain within the same bit-packing family as the other two curves: a decoder written for BLS12-381 could be extended to BN462 by masking two metadata bits instead of three, rather than by acquiring a second, leading-byte parser used only for BN462. It carries a pitfall. Step 2 of determines the curve jointly from C_bit and the length of the string. For BN462 (n = 58, and E' represented over GF(p^2)), an uncompressed point on E and a compressed point on E' both occupy 116 bytes. Under a two-bit variant, compressed forms cannot be represented and C_bit is always 0, so the two cases never both arise; but a decoder that reuses step 2 unmodified would accept a 116-byte string with C_bit set and interpret it as a compressed point on E'. An implementation of such a variant would have to reject a nonzero C_bit before the length-based determination in step 2. An encoding with a dedicated leading byte () does not have this hazard, because the type byte separates the two cases structurally. The variant would also forgo point compression, which is the form most protocols transmit. No implementation of it was found.

Alternative Considered: A Dedicated Leading Byte Moving the metadata out of the coordinate and into a byte of its own removes the constraint of entirely and keeps point compression available, at a cost of one byte. Two mutually incompatible variants are in use:

• The type byte: 0x04 for an uncompressed point, 0x02 or 0x03 for a compressed point with the value itself carrying the parity of y, followed by the coordinates in big-endian order. This is what and emit.
• A flag byte carrying the same three metadata bits as in the same positions (C_bit at 0x80, I_bit at 0x40, S_bit at 0x20, with the remaining five bits zero and checked on input), followed by the coordinates in big-endian order. This is what emits. These are the same bit positions that uses in its bit-packing path, so this variant amounts to relocating the bit assignment of into a leading byte, leaving the rest of the format unchanged.

Both variants yield the same encoded lengths (117 and 59 bytes for G_1, 233 and 117 bytes for G'_2), so length alone does not distinguish them. The leading byte does: an uncompressed point other than the identity element begins with 0x04 in the first variant and 0x00 in the second. A decoder that validates the leading byte rather than skipping over it will therefore reject a string in the other format instead of misparsing it.

Why This Document Does Not Define a Format gives the reasons this document does not specify a BN462 point format. Two of them bear on what is recorded above. No specification examined defines or requires a BN462 point encoding, so the encodings listed here are library conventions rather than a format that a consumer of this document needs; and choosing among them would be encoding design rather than the recording of established practice. Should BN462 point encodings converge, or should a protocol specification come to require one, a separate specification can define one. Of the encodings recorded above, the type byte is the most widely implemented among the libraries examined, and is the form an implementer is most likely to encounter when interoperating with existing BN462 code.

Adoption Status of Pairing-Friendly Curves at Approximately the 100-bit Security Level BN curves including BN254 that were regarded as providing 128-bit security before exTNFS are estimated at approximately 100 bits after exTNFS . The following table summarizes the adoption status of the BN curves with a 254- or 256-bit characteristic, which does not select because their security level is more than 5 bits below the 128-bit level. Please refer to for the naming conventions for each curve.

Category	Name	Supported Curves
Standard	ISO/IEC	BN256I
Standard	TCG	BN256I
Standard	FIDO/W3C	BN256I
Standard	FIDO/W3C	BN256D
Library	mcl	BN254N
Library	mcl	BN_SNARK1
Library	TEPLA	BN254B
Library	TEPLA	BN254N
Library	RELIC	BN254N
Library	RELIC	BN256R
Library	Intel IPP	BN256I
Library	MIRACL	BN254N
Library	MIRACL	BN254CX
Library	MIRACL	BN256I
Library	Adjoint	BN_SNARK1
Library	Adjoint	BN254B
Library	Adjoint	BN254N
Library	Adjoint	BN254S1
Library	Adjoint	BN254S2
Library	libsnark	BN_SNARK1
Library	gnark-crypto	BN_SNARK1
Library	arkworks	BN_SNARK1
Library	noble-curves	BN_SNARK1
Library	constantine	BN254N
Library	constantine	BN_SNARK1
Application	Zcash	BN_SNARK1
Application	Ethereum	BN_SNARK1
Application	Algorand	BN_SNARK1

Scope of the Security Estimate Review states that the security estimates this document cites were reviewed against subsequent work. This appendix records what that review covered and what it did not. The review covered work published between January 2020 and August 2026. Peer-reviewed publications were searched through Crossref, the IACR Cryptology ePrint Archive was searched for preprints, and arXiv was used as a cross-check for work appearing in neither. A result was assessed if it bears on the cost of computing discrete logarithms in the fields GF(p^12) or GF(p^48), or in the elliptic curve groups of the curves recommended here, or on the special and tower variants of the number field sieve that apply to them. The estimates given in and rest on peer-reviewed results. Preprints were used to find work that had not yet appeared in a peer-reviewed venue; , the one result of that kind bearing directly on one of the fields these curves use, has since appeared in the proceedings of CRYPTO 2026. The review is bounded by its end date: it describes what had been published by August 2026, and says nothing about what has been published since.