<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc text-list-symbols="-o*+"?>

<rfc ipr="trust200902" docName="draft-irtf-cfrg-pairing-friendly-curves-01" category="exp">

  <front>
    <title>Pairing-Friendly Curves</title>

    <author initials="Y." surname="Sakemi" fullname="Yumi Sakemi">
      <organization>Lepidum</organization>
      <address>
        <email>yumi.sakemi@lepidum.co.jp</email>
      </address>
    </author>
    <author initials="T." surname="Kobayashi" fullname="Tetsutaro Kobayashi">
      <organization>NTT</organization>
      <address>
        <email>tetsutaro.kobayashi.dr@hco.ntt.co.jp</email>
      </address>
    </author>
    <author initials="T." surname="Saito" fullname="Tsunekazu Saito">
      <organization>NTT</organization>
      <address>
        <email>tsunekazu.saito.hg@hco.ntt.co.jp</email>
      </address>
    </author>

   <date/>

    <area>IRTF</area>
    <workgroup>CFRG</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>Pairing-Friendly Curves</keyword>
    <keyword>Eliptic Curve Cryptgraphy</keyword>

    <abstract>


<t>This memo introduces pairing-friendly curves used for constructing pairing-based cryptography.
It describes recommended parameters for each security level and recent implementations of pairing-friendly curves.</t>


    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<section anchor="pairing-based-cryptography" title="Pairing-Based Cryptography">

<t>Elliptic curve cryptography is one of the important areas in recent cryptography. The cryptographic algorithms based on elliptic curve cryptography, such as ECDSA (Elliptic Curve Digital Signature Algorithm), are widely used in many applications.</t>

<t>Pairing-based cryptography, a variant of elliptic curve cryptography, has attracted the attention for its flexible and applicable functionality.
Pairing is a special map defined over elliptic curves.
Thanks to the characteristics of pairing, it can be applied to construct 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 now in practical use.</t>

<t>As the importance of pairing grows, elliptic curves where pairing is efficiently computable are studied and the special curves called pairing-friendly curves are proposed.</t>

</section>
<section anchor="applications-of-pairing-based-cryptography" title="Applications of Pairing-Based Cryptography">

<t>Several applications using pairing-based cryptography are standardized and implemented. We show example applications available in the real world.</t>

<t>IETF publishes RFCs for pairing-based cryptography such as Identity-Based Cryptography <xref target="RFC5091"/>, Sakai-Kasahara Key Encryption (SAKKE) <xref target="RFC6508"/>, and Identity-Based Authenticated Key Exchange (IBAKE) <xref target="RFC6539"/>. 
SAKKE is applied to Multimedia Internet KEYing (MIKEY) <xref target="RFC6509"/> and used in 3GPP <xref target="SAKKE"/>.</t>

<t>Pairing-based key agreement protocols are standardized in ISO/IEC <xref target="ISOIEC11770-3"/>.
In <xref target="ISOIEC11770-3"/>, a key agreement scheme by Joux <xref target="Joux00"/>, identity-based key agreement schemes by Smart-Chen-Cheng <xref target="CCS07"/> and by Fujioka-Suzuki-Ustaoglu <xref target="FSU10"/> are specified.</t>

<t>MIRACL implements M-Pin, a multi-factor authentication protocol <xref target="M-Pin"/>.
M-Pin protocol includes a kind of zero-knowledge proof, where pairing is used for its construction.</t>

<t>Trusted Computing Group (TCG) specifies ECDAA (Elliptic Curve Direct Anonymous Attestation) in the specification of Trusted Platform Module (TPM) <xref target="TPM"/>. 
ECDAA is a protocol for proving the attestation held by a TPM to a verifier without revealing the attestation held by that TPM. Pairing is used for constructing ECDAA. FIDO Alliance <xref target="FIDO"/> and W3C <xref target="W3C"/> also published ECDAA algorithm similar to TCG.</t>

<!-- Intel SGX EPID -->

<t>Intel introduces Intel Enhanced Privacy ID (EPID) which enables remote attestation of a hardware device while preserving the privacy of the device as a functionality of Intel Software Guard Extensions (SGX) <xref target="EPID"/>. They extend TPM ECDAA to realize such functionality. A pairing-based EPID has been proposed <xref target="BL10"/> and distributed along with Intel SGX applications.</t>

<t>Zcash implements their own zero-knowledge proof algorithm named zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) <xref target="Zcash"/>. zk-SNARKs is used for protecting privacy of transactions of Zcash. They use pairing for constructing zk-SNARKS.</t>

<t>Cloudflare introduces Geo Key Manager <xref target="Cloudflare"/> to restrict distribution of customers’ private keys to the subset of their data centers. To achieve this functionality, attribute-based encryption is used and pairing takes a role as a building block.</t>

<t>Recently, Boneh-Lynn-Shacham (BLS) signature schemes are being standardized 
<xref target="I-D.boneh-bls-signature"/> and utilized in several blockchain projects 
such as Ethereum <xref target="Ethereum"/>, Algorand <xref target="Algorand"/>, Chia Network <xref target="Chia"/> and DFINITY <xref target="DFINITY"/>. 
The aggregation functionality of BLS signatures is effective for their applications of decentralization and scalability.</t>

</section>
<section anchor="goal" title="Goal">

<t>The goal of this memo is to consider the security of pairing-friendly curves used in pairing-based cryptography and introduce secure parameters of pairing-friendly curves. Specifically, we explain the recent attack against pairing-friendly curves and how much the security of the curves is reduced.
We show how to evaluate the security of pairing-friendly curves and give the parameters for 100 bits of security, which is no longer secure, 128, 192 and 256 bits of security.</t>

</section>
<section anchor="requirements-terminology" title="Requirements Terminology">

<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

</section>
</section>
<section anchor="preliminaries" title="Preliminaries">

<section anchor="elliptic-curve" title="Elliptic Curve">

<t>Let p &gt; 3 be a prime and q = p^n for a natural number n.
Let F_q be a finite field.
The curve defined by the following equation E is called an elliptic curve.</t>

<figure><artwork><![CDATA[
   E : y^2 = x^3 + A * x + B,
]]></artwork></figure>

<t>where x and y are in F_q, and A and B in F_q satisfy the discriminant inequality 4 * A^3 + 27 * B^2 != 0 mod q.
This is called Weierstrass normal form of an elliptic curve.</t>

<t>Solutions (x, y) for an elliptic curve E, as well as the point at infinity, O_E, 
are called F_q-rational points.
If P and Q are two points on the curve E, we can define R = P + Q as the opposite point of the intersection between the curve E and the line that passes through P and Q.<vspace />
We can define P + O_E = P = O_E + P as well.
Similarly, we can define 2P = P + P and a scalar multiplication S = [a]P for a positive integer a can be defined as an (a-1)-time addition of P.</t>

<t>The additive group, denoted by E(F_q), is constructed by the set of F_q-rational points and the addition law described above.
We can define the cyclic additive group with a prime order r by taking a base point BP in E(F_q) as a generator. This group is used for the elliptic curve cryptography.</t>

<t>We define terminology used in this memo as follows.</t>

<t><list style="hanging">
  <t hangText='O_E:'>
  the point at infinity over an elliptic curve E.</t>
  <t hangText='E(F_q):'>
  a group constructed by F_q-rational points of E.</t>
  <t hangText='#E(F_q):'>
  the number of F_q-rational points of E.</t>
  <t hangText='h:'>
  a cofactor such that h =  #E(F_q) / r.</t>
</list></t>

</section>
<section anchor="pairing" title="Pairing">

<t>Pairing is a kind of the bilinear map defined over two elliptic curves E and E’.
Examples include Weil pairing, Tate pairing, optimal Ate pairing <xref target="Ver09"/> and so on.
Especially, optimal Ate pairing is considered to be efficient to compute and mainly used for practical implementation.</t>

<t>Let E be an elliptic curve defined over a prime field F_p and E’ be an elliptic curve defined over an extension field of F_p.
Let k be a minimum integer such that r is a divisor of p^k - 1, which is called an embedding degree.
Let G_1 be a cyclic subgroup on the elliptic curve E with order r, 
and G_2 be a cyclic subgroup on the elliptic curve E’ with order r.
Let G_T be an order r subgroup of a multiplicative group (F_p^k)^*.</t>

<t>Pairing is defined as a bilinear map e: (G_1, G_2) -&gt; G_T
satisfying the following properties:</t>

<t><list style="numbers">
  <t>Bilinearity: for any S in G_1, T in G_2, and integers a and b, e([a]S, [b]T) = e(S, T)^{a * b}.</t>
  <t>Non-degeneracy: for any T in G_2, e(S, T) = 1 if and only if S = O_E.
 Similarly, for any S in G_1, e(S, T) = 1 if and only if T = O_E.</t>
  <t>Computability: for any S in G_1 and T in G_2, the bilinear map is efficiently computable.</t>
</list></t>

</section>
<section anchor="BNdef" title="Barreto-Naehrig Curve">

<t>A BN curve <xref target="BN05"/> is one of the instantiations of pairing-friendly curves proposed in 2005. A pairing over BN curves constructs optimal Ate pairings.</t>

<t>A BN curve is defined by elliptic curves E and E’ parameterized by a well chosen integer t.
E is defined over F_p, where p is a prime more than or equal to 5, and E(F_p) has a subgroup of prime order r.
The characteristic p and the order r are parameterized by</t>

<figure><artwork><![CDATA[
    p = 36 * t^4 + 36 * t^3 + 24 * t^2 + 6 * t + 1
    r = 36 * t^4 + 36 * t^3 + 18 * t^2 + 6 * t + 1
]]></artwork></figure>

<t>for an integer t.</t>

<t>The elliptic curve E has an equation of the form E: y^2 = x^3 + b, where b is an element of multiplicative group of order p.</t>

<t>BN curves always have order 6 twists. If m is an element which is neither a square nor a cube in an extension field F_p^2, the twisted curve E’ of E is defined over an extension field F_p^2 by the equation E’: y^2 = x^3 + b’ with b’ = b / m or b’ = b * m. 
BN curves are called D-type if b’ = b / m, and M-type if b’ = b * m.
The embedded degree k is 12.</t>

<t>A pairing e is defined by taking G_1 as a subgroup of E(F_p) of order r, G_2 as a subgroup of E’(F_p^2), and G_T as a subgroup of a multiplicative group (F_p^12)^* of order r.</t>

</section>
<section anchor="BLSdef" title="Barreto-Lynn-Scott Curve">

<t>A BLS curve <xref target="BLS02"/> is another instantiations of pairings proposed in 2002. Similar to BN curves, a pairing over BLS curves constructs optimal Ate pairings.</t>

<t>A BLS curve is elliptic curves E and E’ parameterized by a well chosen integer t.
E is defined over a finite field F_p by an equation of the form E: y^2 = x^3 + b,
and its twisted curve, E’: y^2 = x^3 + b’, is defined in the same way as BN curves. 
In contrast to BN curves, E(F_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 will be defined on the r-torsions points.
In the same way as BN curves, BLS curves can be categorized into D-type and M-type.</t>

<t>BLS curves vary according to different embedding degrees. In this memo, we deal with BLS12 and BLS48 families with embedding degrees 12 and 48 with respect to r, respectively.</t>

<t>In BLS curves, parameterized p and r are given by the following equations:</t>

<figure><artwork><![CDATA[
   BLS12:
       p = (t - 1)^2 * (t^4 - t^2 + 1) / 3 + t
       r = t^4 - t^2 + 1
   BLS48:
       p = (t - 1)^2 * (t^16 - t^8 + 1) / 3 + t
       r = t^16 - t^8 + 1
]]></artwork></figure>

<t>for a well chosen integer t.</t>

<t>A pairing e is defined by taking G_1 as a subgroup of E(F_p) of order r, G_2 as an order r subgroup of E’(F_p^2) for BLS12 and of E’(F_p^8) for BLS48, and G_T as an order r subgroup of a multiplicative group (F_p^12)^* for BLS12 and of a multiplicative group (F_p^48)^* for BLS48.</t>

</section>
<section anchor="representation-convention-for-an-extension-field" title="Representation Convention for an Extension Field">

<t>Pairing-friendly curves use a tower of some extension fields. 
In order to encode an element of an extension field, we adopt the representation convention shown in Appendix J.4 of <xref target="I-D.draft-lwig-curve-representations"/> .</t>

<t>Let F_p be a finite field of characteristic p and F_p^d be an extension field of F_p of degree d and an indeterminate i.</t>

<t>
    For an element s in F_p^d such that s = s_0 + s_1 * i + ... + s_{d - 1} *  i^{d - 1} for s_0, s_1, ... , s_{d - 1} in a basefield F_p, s is represented as octet string by oct(s) = s_0 || s_1 || ... || s_{d - 1}.
</t>

<t>Let F_p^d’ be an extension field of F_p^d of degree d’ / d and an indeterminate j.</t>

<t>
    For an element s’ in F_p^d’ such that s’ = s’_0 + s’_1 * j + ... + s’_{d’ / d - 1} * j^{d’ / d - 1} for s’_0, s’_1, ..., s’_{d’ / d - 1} in a basefield F_p^d, s’ is represented as integer by oct(s’) = oct(s’_0) || oct(s’_1) || ... || oct(s’_{d’ / d - 1}), where oct(s’_0), ... , oct(s’_{d’ / d - 1}) are octet strings encoded by above convention.
</t>

<t>In general, one can define encoding between integer and an element of any finite field tower by inductively applying the above convention.</t>

<t>The parameters and test vectors of extension fields described in this memo are encoded by this convention and represented in octet stream.</t>

<!-- Pairing-friendly curves uses some extension fields. 
In order to encode an element of an extension field, 
we adopt the convention shown in {{IEEE-1363a-2004}}.

Let F\_p be a finite field of characteristic p and F\_p^d be an extension field of F\_p of degree d.
For an element s in F
such that s = s\_0 + s\_1 \* i + s\_2 \* i^2 + ... + s\_{d-1} \* i^{d-1} 
for an indeterminate i and s\_1, ... , s\_{d-1} in a subfield of the extension field, 
s is represented by

        s = s_0 + s_1 * p + s_2 * p^2 + ... + s_{d-1} * p^{d-1},

where p is a characteristic of the subfield.

The parameters and test vectors of extension fields described in this memo 
are encoded by this convention and represented in octet stream. -->

</section>
</section>
<section anchor="security_pfc" title="Security of Pairing-Friendly Curves">

<section anchor="evaluating-the-security-of-pairing-friendly-curves" title="Evaluating the Security of Pairing-Friendly Curves">

<t>The security of pairing-friendly curves is evaluated by the hardness of the following discrete logarithm problems.</t>

<t><list style="symbols">
  <t>The elliptic curve discrete logarithm problem (ECDLP) in G_1 and G_2</t>
  <t>The finite field discrete logarithm problem (FFDLP) in G_T</t>
</list></t>

<t>There are other hard problems over pairing-friendly curves used for proving the security of pairing-based cryptography. Such problems include computational bilinear Diffie-Hellman (CBDH) problem and bilinear Diffie-Hellman (BDH) Problem, decision bilinear Diffie-Hellman (DBDH) problem, gap DBDH problem, etc <xref target="ECRYPT"/>.
Almost all of these variants are reduced to the hardness of discrete logarithm problems described above and believed to be easier than the discrete logarithm problems.</t>

<t>There would be the case where the attacker solves these reduced problems to break pairing-based cryptography. Since such attacks have not been discovered yet, we discuss the hardness of the discrete logarithm problems in this memo.</t>

<t>The security level of pairing-friendly curves is estimated by the computational cost of the most efficient algorithm to solve the above discrete logarithm problems. 
The well-known algorithms for solving the discrete logarithm problems include Pollard’s rho algorithm <xref target="Pollard78"/>, Index Calculus <xref target="HR83"/> and so on. 
In order to make index calculus algorithms more efficient, number field sieve (NFS) algorithms are utilized.</t>

</section>
<section anchor="impact" title="Impact of the Recent Attack">

<t>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 <xref target="KB16"/>.
Due to exTNFS, the security level of 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 bits of security (BN256, for example) dropped down to approximately 100 bits <xref target="BD18"/>.</t>

<t>Some papers showed 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 bits of security, Menezes, Sarkar and Singh estimated the minimum bit length of p of BN curves after exTNFS as 383 bits, and that of BLS12 curves as 384 bits <xref target="MSS17"/>.
For 256 bits of security, Kiyomura et al. estimated the minimum bit length of p^k of BLS48 curves as 27,410 bits, which implied 572 bits of p <xref target="KIK17"/>.</t>

</section>
</section>
<section anchor="secure_params" title="Security Evaluation of Pairing-Friendly Curves">

<t>We give security evaluation for pairing-friendly curves based on the evaluating method presented in <xref target="security_pfc"/>. We also introduce secure parameters of pairing-friendly curves for each security level.
The parameters introduced here are chosen with the consideration of security, efficiency and global acceptance.</t>

<t>For security, we introduce the parameters with 100 bits, 128 bits, 192 bits and 256 bits of security.
We note that 100 bits of security is no longer secure
and recommend 128 bits, 192 bits and 256 bits of security for secure applications.
We follow TLS 1.3 <xref target="RFC8446"/> which specifies the cipher suites with 128 bits and 256 bits of security as mandatory-to-implement for the choice of the security level.</t>

<t>Implementers of the applications have to choose the parameters with appropriate security level according to the security requirements of the applications.
For efficiency, we refer to the benchmark by mcl <xref target="mcl"/> for 128 bits of security, and by Kiyomura et al. <xref target="KIK17"/> for 256 bits of security, and then choose sufficiently efficient parameters.
For global acceptance, we give the implementations of pairing-friendly curves in <xref target="impl"/>.</t>

<section anchor="for-100-bits-of-security" title="For 100 Bits of Security">

<t>Before exTNFS, BN curves with 256-bit size of underlying finite field (so-called BN256) were considered to achieve 128 bits of security. After exTNFS, however, the security level of BN curves with 256-bit size of underlying finite field fell into 100 bits.</t>

<t>Implementers who will newly develop the applications of pairing-based cryptography SHOULD NOT use pairing-friendly curves with 100 bits of security (i.e. BN256).</t>

<t>There exists applications which already implemented pairing-based cryptography with 100-bit secure pairing-friendly curves.
In such a case, implementers MAY use 100 bits of security only if they need to keep interoperability with the existing applications.</t>

</section>
<section anchor="for-128-bits-of-security" title="For 128 Bits of Security">

<section anchor="bn-curves" title="BN Curves">

<t>A BN curve with 128 bits of security is shown in <xref target="BD18"/>, which we call BN462. 
BN462 is defined by a parameter</t>

<figure><artwork><![CDATA[
    t = 2^114 + 2^101 - 2^14 - 1 
]]></artwork></figure>

<t>for the definition in <xref target="BNdef"/>.</t>

<t>For the finite field F_p, the towers of extension field F_p^2, F_p^6 and F_p^12 are defined by indeterminates u, v, w as follows:</t>

<figure><artwork><![CDATA[
    F_p^2 = F_p[u] / (u^2 + 1)
    F_p^6 = F_p^2[v] / (v^3 - u - 2)
    F_p^12 = F_p^6[w] / (w^2 - v).
]]></artwork></figure>

<t>Defined by t, the elliptic curve E and its twisted curve 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-bit length. A pairing e is defined by taking G_1 as a cyclic group of order r generated by a base point BP = (x, y) in F_p, G_2 as a cyclic group of order r generated by a based point BP’ = (x’, y’) in F_p^2, and G_T as a subgroup of a multiplicative group (F_p^12)^* of order r. BN462 is D-type.</t>

<t>We give the following parameters for BN462.</t>

<t><list style="symbols">
  <t>G_1 defined over E: y^2 = x^3 + b
  <list style="symbols">
      <t>p : a characteristic</t>
      <t>r : an order</t>
      <t>BP = (x, y) : a base point</t>
      <t>h : a cofactor</t>
      <t>b : a coefficient of E</t>
    </list></t>
  <t>G_2 defined over E’: y^2 = x^3 + b’
  <list style="symbols">
      <t>r’ : an order</t>
      <t>BP’ = (x’, y’) : a base point (encoded with <xref target="I-D.draft-lwig-curve-representations"/>)
      <list style="symbols">
          <t>x’ = x’_0 + x’_1 * u (x’_0, x’_1 in F_p)</t>
          <t>y’ = y’_0 + y’_1 * u (y’_0, y’_1 in F_p)</t>
        </list></t>
      <t>h’ : a cofactor</t>
      <t>b’ : a coefficient of E’</t>
    </list></t>
</list></t>

<t><list style="hanging">
  <t hangText='p:'>
      0x240480360120023ffffffffff6ff0cf6b7d9bfca0000000000d812908f41c8020ffffffffff6ff66fc6ff687f640000000002401b00840138013
  </t>
  <t hangText='r:'>
      0x240480360120023ffffffffff6ff0cf6b7d9bfca0000000000d812908ee1c201f7fffffffff6ff66fc7bf717f7c0000000002401b007e010800d
  </t>
  <t hangText='x:'>
      0x21a6d67ef250191fadba34a0a30160b9ac9264b6f95f63b3edbec3cf4b2e689db1bbb4e69a416a0b1e79239c0372e5cd70113c98d91f36b6980d
  </t>
  <t hangText='y:'>
      0x0118ea0460f7f7abb82b33676a7432a490eeda842cccfa7d788c659650426e6af77df11b8ae40eb80f475432c66600622ecaa8a5734d36fb03de
  </t>
  <t hangText='h:'>
  1</t>
  <t hangText='b:'>
  5</t>
  <t hangText='r’:'>
      0x240480360120023ffffffffff6ff0cf6b7d9bfca0000000000d812908ee1c201f7fffffffff6ff66fc7bf717f7c0000000002401b007e010800d
  </t>
  <t hangText='x’_0:'>
      0x0257ccc85b58dda0dfb38e3a8cbdc5482e0337e7c1cd96ed61c913820408208f9ad2699bad92e0032ae1f0aa6a8b48807695468e3d934ae1e4df
  </t>
  <t hangText='x’_1:'>
      0x1d2e4343e8599102af8edca849566ba3c98e2a354730cbed9176884058b18134dd86bae555b783718f50af8b59bf7e850e9b73108ba6aa8cd283
  </t>
  <t hangText='y’_0:'>
      0x0a0650439da22c1979517427a20809eca035634706e23c3fa7a6bb42fe810f1399a1f41c9ddae32e03695a140e7b11d7c3376e5b68df0db7154e
  </t>
  <t hangText='y’_1:'>
      0x073ef0cbd438cbe0172c8ae37306324d44d5e6b0c69ac57b393f1ab370fd725cc647692444a04ef87387aa68d53743493b9eba14cc552ca2a93a
  </t>

  <t hangText='h’:'>
      0x240480360120023ffffffffff6ff0cf6b7d9bfca0000000000d812908fa1ce0227fffffffff6ff66fc63f5f7f4c0000000002401b008a0168019
  </t>
  <t hangText='b’:'>
  -u + 2</t>
</list></t>

</section>
<section anchor="bls-curves" title="BLS Curves">

<t>A BLS12 curve with 128 bits of security shown in <xref target="BLS12-381"/>, BLS12-381, 
is defined by a parameter</t>

<figure><artwork><![CDATA[
    t = -2^63 - 2^62 - 2^60 - 2^57 - 2^48 - 2^16 
]]></artwork></figure>

<t>and the size of p becomes 381-bit length.</t>

<t>For the finite field F_p, the towers of extension field F_p^2, F_p^6 and F_p^12 are defined by indeterminates u, v, w as follows:</t>

<figure><artwork><![CDATA[
    F_p^2 = F_p[u] / (u^2 + 1)
    F_p^6 = F_p^2[v] / (v^3 - u - 1)
    F_p^12 = F_p^6[w] / (w^2 - v).
]]></artwork></figure>

<t>Defined by t, the elliptic curve E and its twisted curve E’ are represented 
by E: y^2 = x^3 + 4 and E’: y^2 = x^3 + 4(u + 1).</t>

<t>A pairing e is defined by taking G_1 as a cyclic group of order r generated by a base point BP = (x, y) in F_p, G_2 as a cyclic group of order r generated by a based point BP’ = (x’, y’) in F_p^2, and G_T as a subgroup of a multiplicative group (F_p^12)^* of order r. BLS12-381 is M-type.</t>

<t>We have to note that, according to <xref target="MSS17"/>, the bit length of p for BLS12 to achieve 128 bits of security is calculated as 384 bits and more, which BLS12-381 does not satisfy. They state that BLS12-381 achieves 127-bit security level evaluated by the computational cost of Pollard’s rho, whereas NCC group estimated that the security level of BLS12-381 is between 117 and 120 bits at most <xref target="NCCG"/>.
Therefore, we regard BN462 as a "conservative" parameter, and BLS12-381 as an "optimistic" parameter.</t>

<t>We give the following parameters for BLS12-381.</t>

<t><list style="symbols">
  <t>G_1 defined over E: y^2 = x^3 + b
  <list style="symbols">
      <t>p : a characteristic</t>
      <t>r : an order</t>
      <t>BP = (x, y) : a base point</t>
      <t>h : a cofactor</t>
      <t>b : a coefficient of E</t>
    </list></t>
  <t>G_2 defined over E’: y^2 = x^3 + b’
  <list style="symbols">
      <t>r’ : an order</t>
      <t>BP’ = (x’, y’) : a base point (encoded with <xref target="I-D.draft-lwig-curve-representations"/>)
      <list style="symbols">
          <t>x’ = x’_0 + x’_1 * u (x’_0, x’_1 in F_p)</t>
          <t>y’ = y’_0 + y’_1 * u (y’_0, y’_1 in F_p)</t>
        </list></t>
      <t>h’ : a cofactor</t>
      <t>b’ : a coefficient of E’</t>
    </list></t>
</list></t>

<t><list style="hanging">
  <t hangText='p:'>
      0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
  </t>
  <t hangText='r:'>
      0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001
  </t>
  <t hangText='x:'>
      0x17f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb
  </t>
  <t hangText='y:'>
      0x08b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1
  </t>
  <t hangText='h:'>
      0x396c8c005555e1568c00aaab0000aaab
  </t>
  <t hangText='b:'>
  4</t>
  <t hangText='r’:'>
      0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
  </t>
  <t hangText='x’_0:'>
      0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb8
  </t>
  <t hangText='x’_1:'>
      0x13e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e
  </t>
  <t hangText='y’_0:'>
      0x0ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801
  </t>
  <t hangText='y’_1:'>
      0x0606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be
  </t>
  <t hangText='h’:'>
      0x5d543a95414e7f1091d50792876a202cd91de4547085abaa68a205b2e5a7ddfa628f1cb4d9e82ef21537e293a6691ae1616ec6e786f0c70cf1c38e31c7238e5
  </t>
  <t hangText='b’:'>
  4 * (u + 1)</t>
</list></t>

</section>
</section>
<section anchor="for-192-bits-of-security" title="For 192 Bits of Security">

<t>(TBD)</t>

</section>
<section anchor="for-256-bits-of-security" title="For 256 Bits of Security">

<t>As shown in <xref target="impact"/>, it is unrealistic to achieve 256 bits of security by BN curves 
since the minimum size of p becomes too large to implement.
Hence, we consider BLS48 for 256 bits of security.</t>

<t>A BLS48 curve with 256 bits of security is shown in <xref target="KIK17"/>, which we call BLS48-581. 
It is defined by a parameter</t>

<figure><artwork><![CDATA[
    t = -1 + 2^7 - 2^10 - 2^30 - 2^32. 
]]></artwork></figure>

<t>For the finite field F_p, the towers of extension field F_p^2, F_p^4, F_p^8, F_p^24 and F_p^48 are defined by indeterminates u, v, w, z, s as follows:</t>

<figure><artwork><![CDATA[
    F_p^2 = F_p[u] / (u^2 + 1)
    F_p^4 = F_p^2[v] / (v^2 + u + 1)
    F_p^8 = F_p^4[w] / (w^2 + v)
    F_p^24 = F_p^8[z] / (z^3 + w)
    F_p^48 = F_p^24[s] / (s^2 + z).
]]></artwork></figure>

<t>The elliptic curve E and its twisted curve E’ are represented by E: y^2 = x^3 + 1 
and E’: y^2 = x^3 - 1 / w.
A pairing e is defined by taking G_1 as a cyclic group of order r generated by a base point BP = (x, y) in F_p, G_2 as a cyclic group of order r generated by a based point BP’ = (x’, y’) in F_p^8, and G_T as a subgroup of a multiplicative group (F_p^48)^* of order r.
The size of p becomes 581-bit length. BLS48-581 is D-type.</t>

<t>We then give the parameters for BLS48-581 as follows.</t>

<t><list style="symbols">
  <t>G_1 defined over E: y^2 = x^3 + b
  <list style="symbols">
      <t>p : a characteristic</t>
      <t>r : a prime which divides an order of G_1</t>
      <t>BP = (x, y) : a base point</t>
      <t>h : a cofactor</t>
      <t>b : a coefficient of E</t>
    </list></t>
  <t>G_2 defined over E’: y^2 = x^3 + b’
  <list style="symbols">
      <t>r’ : an order</t>
      <t>BP’ = (x’, y’) : a base point (encoded with <xref target="I-D.draft-lwig-curve-representations"/>)
      <list style="symbols">
          <t>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 F_p)</t>
          <t>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 F_p)</t>
        </list></t>
      <t>h’ : a cofactor</t>
      <t>b’ : a coefficient of E’</t>
    </list></t>
</list></t>

  <t><list style="hanging">
  <t hangText='p:'>
      0x1280f73ff3476f313824e31d47012a0056e84f8d122131bb3be6c0f1f3975444a48ae43af6e082acd9cd30394f4736daf68367a5513170ee0a578fdf721a4a48ac3edc154e6565912b
  </t>
  <t hangText='r:'>
      0x2386f8a925e2885e233a9ccc1615c0d6c635387a3f0b3cbe003fad6bc972c2e6e741969d34c4c92016a85c7cd0562303c4ccbe599467c24da118a5fe6fcd671c01
  </t>
  <t hangText='x:'>
      0x02af59b7ac340f2baf2b73df1e93f860de3f257e0e86868cf61abdbaedffb9f7544550546a9df6f9645847665d859236ebdbc57db368b11786cb74da5d3a1e6d8c3bce8732315af640
  </t>
  <t hangText='y:'>
      0x0cefda44f6531f91f86b3a2d1fb398a488a553c9efeb8a52e991279dd41b720ef7bb7beffb98aee53e80f678584c3ef22f487f77c2876d1b2e35f37aef7b926b576dbb5de3e2587a70
  </t>

<!-- x' and y' -->
<t hangText='x’_0:'>
    0x05d615d9a7871e4a38237fa45a2775debabbefc70344dbccb7de64db3a2ef156c46ff79baad1a8c42281a63ca0612f400503004d80491f510317b79766322154dec34fd0b4ace8bfab
  </t>
  <t hangText='x’_1:'>
    0x07c4973ece2258512069b0e86abc07e8b22bb6d980e1623e9526f6da12307f4e1c3943a00abfedf16214a76affa62504f0c3c7630d979630ffd75556a01afa143f1669b36676b47c57
  </t>
  <t hangText='x’_2:'>
    0x01fccc70198f1334e1b2ea1853ad83bc73a8a6ca9ae237ca7a6d6957ccbab5ab6860161c1dbd19242ffae766f0d2a6d55f028cbdfbb879d5fea8ef4cded6b3f0b46488156ca55a3e6a
  </t>
  <t hangText='x’_3:'>
    0x0be2218c25ceb6185c78d8012954d4bfe8f5985ac62f3e5821b7b92a393f8be0cc218a95f63e1c776e6ec143b1b279b9468c31c5257c200ca52310b8cb4e80bc3f09a7033cbb7feafe
  </t>
  <t hangText='x’_4:'>
    0x038b91c600b35913a3c598e4caa9dd63007c675d0b1642b5675ff0e7c5805386699981f9e48199d5ac10b2ef492ae589274fad55fc1889aa80c65b5f746c9d4cbb739c3a1c53f8cce5
  </t>
  <t hangText='x’_5:'>
    0x0c96c7797eb0738603f1311e4ecda088f7b8f35dcef0977a3d1a58677bb037418181df63835d28997eb57b40b9c0b15dd7595a9f177612f097fc7960910fce3370f2004d914a3c093a
  </t>
  <t hangText='x’_6:'>
    0x0b9b7951c6061ee3f0197a498908aee660dea41b39d13852b6db908ba2c0b7a449cef11f293b13ced0fd0caa5efcf3432aad1cbe4324c22d63334b5b0e205c3354e41607e60750e057
  </t>
  <t hangText='x’_7:'>
    0x0827d5c22fb2bdec5282624c4f4aaa2b1e5d7a9defaf47b5211cf741719728a7f9f8cfca93f29cff364a7190b7e2b0d4585479bd6aebf9fc44e56af2fc9e97c3f84e19da00fbc6ae34
  </t>

  <t hangText='y’_0:'>
    0x00eb53356c375b5dfa497216452f3024b918b4238059a577e6f3b39ebfc435faab0906235afa27748d90f7336d8ae5163c1599abf77eea6d659045012ab12c0ff323edd3fe4d2d7971
  </t>
  <t hangText='y’_1:'>
    0x0284dc75979e0ff144da6531815fcadc2b75a422ba325e6fba01d72964732fcbf3afb096b243b1f192c5c3d1892ab24e1dd212fa097d760e2e588b423525ffc7b111471db936cd5665
  </t>
  <t hangText='y’_2:'>
    0x0b36a201dd008523e421efb70367669ef2c2fc5030216d5b119d3a480d370514475f7d5c99d0e90411515536ca3295e5e2f0c1d35d51a652269cbc7c46fc3b8fde68332a526a2a8474
  </t>
  <t hangText='y’_3:'>
    0x0aec25a4621edc0688223fbbd478762b1c2cded3360dcee23dd8b0e710e122d2742c89b224333fa40dced2817742770ba10d67bda503ee5e578fb3d8b8a1e5337316213da92841589d
  </t>
  <t hangText='y’_4:'>
    0x0d209d5a223a9c46916503fa5a88325a2554dc541b43dd93b5a959805f1129857ed85c77fa238cdce8a1e2ca4e512b64f59f430135945d137b08857fdddfcf7a43f47831f982e50137
  </t>
  <t hangText='y’_5:'>
    0x07d0d03745736b7a513d339d5ad537b90421ad66eb16722b589d82e2055ab7504fa83420e8c270841f6824f47c180d139e3aafc198caa72b679da59ed8226cf3a594eedc58cf90bee4
  </t>
  <t hangText='y’_6:'>
    0x0896767811be65ea25c2d05dfdd17af8a006f364fc0841b064155f14e4c819a6df98f425ae3a2864f22c1fab8c74b2618b5bb40fa639f53dccc9e884017d9aa62b3d41faeafeb23986
  </t>
  <t hangText='y’_7:'>
    0x035e2524ff89029d393a5c07e84f981b5e068f1406be8e50c87549b6ef8eca9a9533a3f8e69c31e97e1ad0333ec719205417300d8c4ab33f748e5ac66e84069c55d667ffcb732718b6
  </t>

  <t hangText='h:'>
      0x85555841aaaec4ac
  </t>
  <t hangText='b:'>
  1</t>
  <t hangText='r’:'>
      0x2386f8a925e2885e233a9ccc1615c0d6c635387a3f0b3cbe003fad6bc972c2e6e741969d34c4c92016a85c7cd0562303c4ccbe599467c24da118a5fe6fcd671c01
  </t>
  <t hangText='h’:'>
      0x170e915cb0a6b7406b8d94042317f811d6bc3fc6e211ada42e58ccfcb3ac076a7e4499d700a0c23dc4b0c078f92def8c87b7fe63e1eea270db353a4ef4d38b5998ad8f0d042ea24c8f02be1c0c83992fe5d7725227bb27123a949e0876c0a8ce0a67326db0e955dcb791b867f31d6bfa62fbdd5f44a00504df04e186fae033f1eb43c1b1a08b6e086eff03c8fee9ebdd1e191a8a4b0466c90b389987de5637d5dd13dab33196bd2e5afa6cd19cf0fc3fc7db7ece1f3fac742626b1b02fcee04043b2ea96492f6afa51739597c54bb78aa6b0b99319fef9d09f768831018ee6564c68d054c62f2e0b4549426fec24ab26957a669dba2a2b6945ce40c9aec6afdeda16c79e15546cd7771fa544d5364236690ea06832679562a68731420ae52d0d35a90b8d10b688e31b6aee45f45b7a5083c71732105852decc888f64839a4de33b99521f0984a418d20fc7b0609530e454f0696fa2a8075ac01cc8ae3869e8d0fe1f3788ffac4c01aa2720e431da333c83d9663bfb1fb7a1a7b90528482c6be7892299030bb51a51dc7e91e9156874416bf4c26f1ea7ec578058563960ef92bbbb8632d3a1b695f954af10e9a78e40acffc13b06540aae9da5287fc4429485d44e6289d8c0d6a3eb2ece35012452751839fb48bc14b515478e2ff412d930ac20307561f3a5c998e6bcbfebd97effc6433033a2361bfcdc4fc74ad379a16c6dea49c209b1
  </t>
  <t hangText='b’:'>
  -1 / w</t>
</list></t>

</section>
</section>
<section anchor="impl" title="Implementations of Pairing-Friendly Curves">

<t>We show the pairing-friendly curves selected by existing standards, cryptographic libraries and applications.</t>

<!-- standards -->

<t>ISO/IEC 15946-5 <xref target="ISOIEC15946-5"/> shows examples of BN curves with the size of 160, 192, 224, 256, 384 and 512 bits of p. There is no action so far after the proposal of exTNFS.</t>

<t>TCG adopts an BN curve of 256 bits specified in ISO/IEC 15946-5 (TPM_ECC_BN_P256) and that of 638 bits specified by their own (TPM_ECC_BN_P638).
FIDO Alliance <xref target="FIDO"/> and W3C <xref target="W3C"/> adopt the same BN curves as TCG, a 512-bit BN curve shown in ISO/IEC 15946-5 and another 256-bit BN curve.</t>

<!-- libraries -->

<t>Cryptographic libraries which implement pairings include PBC <xref target="PBC"/>, mcl <xref target="mcl"/>, RELIC <xref target="RELIC"/>, TEPLA <xref target="TEPLA"/>, AMCL <xref target="AMCL"/>, Intel IPP <xref target="Intel-IPP"/> and a library by Kyushu University <xref target="BLS48"/>.</t>

<t>Cloudflare published a new cryptographic library CIRCL (Cloudflare Interoperable, Reusable Cryptographic Library) in 2019 <xref target="CIRCL"/>. The plan for the implementation of secure pairing-friendly curves is stated in their roadmap.</t>

<!-- applications -->

<t>MIRACL implements BN curves and BLS12 curves <xref target="MIRACL"/>.</t>

<t>Zcash implements a BN curve (named BN128) in their library libsnark <xref target="libsnark"/>.
After exTNFS, they propose a new parameter of BLS12 as BLS12-381 <xref target="BLS12-381"/>
and publish its experimental implementation <xref target="zkcrypto"/>.</t>

<t>Ethereum 2.0 adopts BLS12-381 (BLS12_381), BN curves with 254 bits of p (CurveFp254BNb) and 382 bits of p (CurveFp382_1 and CurveFp382_2) <xref target="go-bls"/>. Their implementation calls mcl <xref target="mcl"/> for pairing computation. Chia Network publishs their implementation <xref target="Chia"/> by integrating the RELIC toolkit <xref target="RELIC"/>.</t>

<t><xref target="adoption"/> shows the adoption of pairing-friendly curves in existing standards, cryptographic libraries and applications.
In this table, the curves marked as (*) indicate that the security level is evaluated less than the one labeld in the table.</t>

<texttable title="Adoption of Pairing-Friendly Curves" anchor="adoption">
      <ttcol align='left'>Name</ttcol>
      <ttcol align='left'>100 bit</ttcol>
      <ttcol align='left'>128 bit</ttcol>
      <ttcol align='left'>192 bit</ttcol>
      <ttcol align='left'>256 bit</ttcol>
      <c>ISO/IEC 15946-5</c>
      <c>BN256</c>
      <c>BN384</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>TCG</c>
      <c>BN256</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>FIDO/W3C</c>
      <c>BN256</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>PBC</c>
      <c>BN</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>mcl</c>
      <c>BN254 / BN_SNARK1</c>
      <c>BN381_1 (*) / BN462 / BLS12-381</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>RELIC</c>
      <c>BN254 / BN256</c>
      <c>BLS12-381 / BLS12-455</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>TEPLA</c>
      <c>BN254</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>AMCL</c>
      <c>BN254 / BN256</c>
      <c>BLS12-381 (*) / BLS12-383 (*) / BLS12-461</c>
      <c>&#160;</c>
      <c>BLS48</c>
      <c>Intel IPP</c>
      <c>BN256</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>Kyushu Univ.</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>BLS48</c>
      <c>MIRACL</c>
      <c>BN254</c>
      <c>BLS12</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>Zcash</c>
      <c>BN128 (CurveSNARK)</c>
      <c>BLS12-381</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>Ethereum</c>
      <c>BN254</c>
      <c>BN382 (*) / BLS12-381 (*)</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>Chia Network</c>
      <c>&#160;</c>
      <c>BLS12-381 (*)</c>
      <c>&#160;</c>
      <c>&#160;</c>
</texttable>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This memo entirely describes the security of pairing-friendly curves, and introduces secure parameters of pairing-friendly curves. We give these parameters in terms of security, efficiency and global acceptance. The parameters for 100, 128, 192 and 256 bits of security are introduced since the security level will different in the requirements of the pairing-based applications. Implementers can select these parameters according to their security requirements.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no actions for IANA.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>The authors would like to thank Akihiro Kato and Shoko Yonezawa for their significant contribution to the early version of this memo.
The authors would also like to acknowledge Sakae Chikara, Hoeteck Wee, Sergey Gorbunov and Michael Scott for their valuable comments.</t>

<!-- # Change log -->

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor="Ver09" >
  <front>
    <title>Optimal Pairings</title>
    <author initials="F." surname="Vercauteren" fullname="Frederik Vercauteren">
      <organization></organization>
    </author>
    <date year="2010" month="January"/>
  </front>
  <seriesInfo name="IEEE Transactions on Information Theory" value="Vol. 56, pp. 455-461"/>
  <seriesInfo name="DOI" value="10.1109/tit.2009.2034881"/>
</reference>

<reference anchor="BN05" >
  <front>
    <title>Pairing-Friendly Elliptic Curves of Prime Order</title>
    <author initials="P." surname="Barreto" fullname="Paulo S. L. M. Barreto">
      <organization></organization>
    </author>
    <author initials="M." surname="Naehrig" fullname="Michael Naehrig">
      <organization></organization>
    </author>
    <date year="2006"/>
  </front>
  <seriesInfo name="Selected Areas in Cryptography" value="pp. 319-331"/>
  <seriesInfo name="DOI" value="10.1007/11693383_22"/>
</reference>

<reference anchor="BLS02" >
  <front>
    <title>Constructing Elliptic Curves with Prescribed Embedding Degrees</title>
    <author initials="P." surname="Barreto" fullname="Paulo S. L. M. Barreto">
      <organization></organization>
    </author>
    <author initials="B." surname="Lynn" fullname="Ben Lynn">
      <organization></organization>
    </author>
    <author initials="M." surname="Scott" fullname="Michael Scott">
      <organization></organization>
    </author>
    <date year="2003"/>
  </front>
  <seriesInfo name="Security in Communication Networks" value="pp. 257-267"/>
  <seriesInfo name="DOI" value="10.1007/3-540-36413-7_19"/>
</reference>

<reference anchor="KB16" >
  <front>
    <title>Extended Tower Number Field Sieve: A New Complexity for the Medium Prime Case</title>
    <author initials="T." surname="Kim" fullname="Taechan Kim">
      <organization></organization>
    </author>
    <author initials="R." surname="Barbulescu" fullname="Razvan Barbulescu">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
  <seriesInfo name="Advances in Cryptology – CRYPTO 2016" value="pp. 543-571"/>
  <seriesInfo name="DOI" value="10.1007/978-3-662-53018-4_20"/>
</reference>

<reference anchor="BD18" >
  <front>
    <title>Updating Key Size Estimations for Pairings</title>
    <author initials="R." surname="Barbulescu" fullname="Razvan Barbulescu">
      <organization></organization>
    </author>
    <author initials="S." surname="Duquesne" fullname="Sylvain Duquesne">
      <organization></organization>
    </author>
    <date year="2018" month="January"/>
  </front>
  <seriesInfo name="Journal of" value="Cryptology"/>
  <seriesInfo name="DOI" value="10.1007/s00145-018-9280-5"/>
</reference>

<reference anchor="MSS17" >
  <front>
    <title>Challenges with Assessing the Impact of NFS Advances on the Security of Pairing-Based Cryptography</title>
    <author initials="A." surname="Menezes" fullname="Alfred Menezes">
      <organization></organization>
    </author>
    <author initials="P." surname="Sarkar" fullname="Palash Sarkar">
      <organization></organization>
    </author>
    <author initials="S." surname="Singh" fullname="Shashank Singh">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
  <seriesInfo name="Lecture Notes in Computer Science" value="pp. 83-108"/>
  <seriesInfo name="DOI" value="10.1007/978-3-319-61273-7_5"/>
</reference>

<reference anchor="KIK17" >
  <front>
    <title>Secure and Efficient Pairing at 256-Bit Security Level</title>
    <author initials="Y." surname="Kiyomura" fullname="Yutaro Kiyomura">
      <organization></organization>
    </author>
    <author initials="A." surname="Inoue" fullname="Akiko Inoue">
      <organization></organization>
    </author>
    <author initials="Y." surname="Kawahara" fullname="Yuto Kawahara">
      <organization></organization>
    </author>
    <author initials="M." surname="Yasuda" fullname="Masaya Yasuda">
      <organization></organization>
    </author>
    <author initials="T." surname="Takagi" fullname="Tsuyoshi Takagi">
      <organization></organization>
    </author>
    <author initials="T." surname="Kobayashi" fullname="Tetsutaro Kobayashi">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
  <seriesInfo name="Applied Cryptography and Network Security" value="pp. 59-79"/>
  <seriesInfo name="DOI" value="10.1007/978-3-319-61204-1_4"/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC5091" target='https://www.rfc-editor.org/info/rfc5091'>
<front>
<title>Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems</title>
<author initials='X.' surname='Boyen' fullname='X. Boyen'><organization /></author>
<author initials='L.' surname='Martin' fullname='L. Martin'><organization /></author>
<date year='2007' month='December' />
<abstract><t>This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption.  This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='5091'/>
<seriesInfo name='DOI' value='10.17487/RFC5091'/>
</reference>



<reference  anchor="RFC6508" target='https://www.rfc-editor.org/info/rfc6508'>
<front>
<title>Sakai-Kasahara Key Encryption (SAKKE)</title>
<author initials='M.' surname='Groves' fullname='M. Groves'><organization /></author>
<date year='2012' month='February' />
<abstract><t>In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described.  This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver.  This  document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6508'/>
<seriesInfo name='DOI' value='10.17487/RFC6508'/>
</reference>



<reference  anchor="RFC6539" target='https://www.rfc-editor.org/info/rfc6539'>
<front>
<title>IBAKE: Identity-Based Authenticated Key Exchange</title>
<author initials='V.' surname='Cakulev' fullname='V. Cakulev'><organization /></author>
<author initials='G.' surname='Sundaram' fullname='G. Sundaram'><organization /></author>
<author initials='I.' surname='Broustis' fullname='I. Broustis'><organization /></author>
<date year='2012' month='March' />
<abstract><t>Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management.  The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility.  However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences.  Another observed deficiency is a lack of mutual authentication of communicating parties.  This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol.  IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6539'/>
<seriesInfo name='DOI' value='10.17487/RFC6539'/>
</reference>



<reference  anchor="RFC6509" target='https://www.rfc-editor.org/info/rfc6509'>
<front>
<title>MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)</title>
<author initials='M.' surname='Groves' fullname='M. Groves'><organization /></author>
<date year='2012' month='February' />
<abstract><t>This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication.  MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery.  This document is not an Internet  Standards Track specification; it is published for informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6509'/>
<seriesInfo name='DOI' value='10.17487/RFC6509'/>
</reference>


<reference anchor="SAKKE" >
  <front>
    <title>Security of the mission critical service (Release 15)</title>
    <author >
      <organization>3GPP</organization>
    </author>
    <date year="2018"/>
  </front>
  <seriesInfo name="3GPP TS" value="33.180 15.3.0"/>
</reference>
<reference anchor="ISOIEC11770-3" >
  <front>
    <title>ISO/IEC 11770-3:2015</title>
    <author >
      <organization>ISO/IEC</organization>
    </author>
    <date year="2015"/>
  </front>
  <seriesInfo name="ISO/IEC" value="Information technology -- Security techniques -- Key management -- Part 3: Mechanisms using asymmetric techniques"/>
</reference>


<reference anchor="Joux00" >
  <front>
    <title>A One Round Protocol for Tripartite Diffie–Hellman</title>
    <author initials="A." surname="Joux" fullname="Antoine Joux">
      <organization></organization>
    </author>
    <date year="2000"/>
  </front>
  <seriesInfo name="Lecture Notes in Computer Science" value="pp. 385-393"/>
  <seriesInfo name="DOI" value="10.1007/10722028_23"/>
</reference>

<reference anchor="CCS07" >
  <front>
    <title>Identity-based key agreement protocols from pairings</title>
    <author initials="L." surname="Chen" fullname="L. Chen">
      <organization></organization>
    </author>
    <author initials="Z." surname="Cheng" fullname="Z. Cheng">
      <organization></organization>
    </author>
    <author initials="N." surname="Smart" fullname="N. P. Smart">
      <organization></organization>
    </author>
    <date year="2007" month="January"/>
  </front>
  <seriesInfo name="International Journal of Information Security" value="Vol. 6, pp. 213-241"/>
  <seriesInfo name="DOI" value="10.1007/s10207-006-0011-9"/>
</reference>

<reference anchor="FSU10" >
  <front>
    <title>Ephemeral Key Leakage Resilient and Efficient ID-AKEs That Can Share Identities, Private and Master Keys</title>
    <author initials="A." surname="Fujioka" fullname="Atsushi Fujioka">
      <organization></organization>
    </author>
    <author initials="K." surname="Suzuki" fullname="Koutarou Suzuki">
      <organization></organization>
    </author>
    <author initials="B." surname="Ustaoglu" fullname="Berkant Ustaoglu">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
  <seriesInfo name="Lecture Notes in Computer Science" value="pp. 187-205"/>
  <seriesInfo name="DOI" value="10.1007/978-3-642-17455-1_12"/>
</reference>


<reference anchor="M-Pin" target="https://www.miracl.com/miracl-labs/m-pin-a-multi-factor-zero-knowledge-authentication-protocol">
  <front>
    <title>M-Pin: A Multi-Factor Zero Knowledge Authentication Protocol</title>
    <author initials="M." surname="Scott">
      <organization></organization>
    </author>
    <date year="2019" month="July"/>
  </front>
</reference>
<reference anchor="TPM" target="https://trustedcomputinggroup.org/resource/tpm-library-specification/">
  <front>
    <title>Trusted Platform Module Library Specification, Family \“2.0\”, Level 00, Revision 01.38</title>
    <author >
      <organization>Trusted Computing Group (TCG)</organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="FIDO" target="https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-ecdaa-algorithm-v2.0-rd-20180702.html">
  <front>
    <title>FIDO ECDAA Algorithm - FIDO Alliance Review Draft 02</title>
    <author initials="R." surname="Lindemann">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="W3C" target="https://www.w3.org/TR/webauthn/">
  <front>
    <title>Web Authentication: An API for accessing Public Key Credentials Level 1 - W3C Recommendation</title>
    <author initials="E." surname="Lundberg">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="EPID" target="https://software.intel.com/en-us/download/intel-sgx-intel-epid-provisioning-and-attestation-services">
  <front>
    <title>Intel (R) SGX: Intel (R) EPID Provisioning and Attestation Services</title>
    <author >
      <organization>Intel Corporation</organization>
    </author>
    <date />
  </front>
</reference>


<reference anchor="BL10" >
  <front>
    <title>Enhanced Privacy ID from Bilinear Pairing for Hardware Authentication and Attestation</title>
    <author initials="E." surname="Brickell" fullname="Ernie Brickell">
      <organization></organization>
    </author>
    <author initials="J." surname="Li" fullname="Jiangtao Li">
      <organization></organization>
    </author>
    <date year="2010" month="August"/>
  </front>
  <seriesInfo name="2010 IEEE Second International Conference on Social" value="Computing"/>
  <seriesInfo name="DOI" value="10.1109/socialcom.2010.118"/>
</reference>


<reference anchor="Zcash" target="https://z.cash/technology/zksnarks.html">
  <front>
    <title>What are zk-SNARKs?</title>
    <author initials="R." surname="Lindemann">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="Cloudflare" target="https://blog.cloudflare.com/geo-key-manager-how-it-works/">
  <front>
    <title>Geo Key Manager: How It Works</title>
    <author initials="N." surname="Sullivan">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>


<reference anchor="I-D.draft-lwig-curve-representations">
    <front>
        <title>Alternative Elliptic Curve Representations</title>
        <author initials='R.' surname='Struik'>
            <organization /></author>
            <date year='2019' month='July' />
    </front>
    <seriesInfo value="draft-ietf-lwig-curve-representations-08" name="Internet-Draft"/>
    <format target="https://www.ietf.org/id/draft-ietf-lwig-curve-representations-08.txt" type="TXT"/>
</reference>


<reference anchor="I-D.boneh-bls-signature">
<front>
<title>BLS Signature Scheme</title>

<author initials='D' surname='Boneh' fullname='Dan Boneh'>
    <organization />
</author>

<author initials='S' surname='Gorbunov' fullname='Sergey Gorbunov'>
    <organization />
</author>

<author initials='H' surname='Wee' fullname='Hoeteck Wee'>
    <organization />
</author>

<author initials='Z' surname='Zhang' fullname='Zhenfei Zhang'>
    <organization />
</author>

<date month='February' day='8' year='2019' />

<abstract><t>The BLS signature scheme was introduced by Boneh-Lynn-Shacham in 2001.  The signature scheme relies on pairing-friendly curves and supports non-interactive aggregation properties.  That is, given a collection of signatures (sigma_1, ..., sigma_n), anyone can produce a short signature (sigma) that authenticates the entire collection. BLS signature scheme is simple, efficient and can be used in a variety of network protocols and systems to compress signatures or certificate chains.  This document specifies the BLS signature and the aggregation algorithms.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-boneh-bls-signature-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-boneh-bls-signature-00.txt' />
</reference>


<reference anchor="Ethereum" target="https://medium.com/prysmatic-labs/ethereum-2-0-development-update-17-prysmatic-labs-ed5bcf82ec00">
  <front>
    <title>Ethereum 2.0 Development Update #17 - Prysmatic Labs</title>
    <author initials="R." surname="Jordan">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="Algorand" target="https://medium.com/algorand/digital-signatures-for-blockchains-5820e15fbe95">
  <front>
    <title>Efficient and Secure Digital Signatures for Proof-of-Stake Blockchains</title>
    <author initials="S." surname="Gorbunov">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="Chia" target="https://github.com/Chia-Network/bls-signatures">
  <front>
    <title>BLS signatures in C++, using the relic toolkit</title>
    <author >
      <organization>Chia Network</organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="DFINITY" target="https://dfinity.org/pdf-viewer/library/dfinity-consensus.pdf">
  <front>
    <title>DFINITY Technology Overview Series Consensus System Rev. 1</title>
    <author initials="D." surname="Williams">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>

<!--
<reference anchor="IEEE-1363a-2004" >
  <front>
    <title>IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
  <seriesInfo name="IEEE" value="standard"/>
  <seriesInfo name="DOI" value="10.1109/ieeestd.2004.94612"/>
</reference>
-->

<reference anchor="ECRYPT" >
  <front>
    <title>Final Report on Main Computational Assumptions in Cryptography</title>
    <author >
      <organization>ECRYPT</organization>
    </author>
    <date />
  </front>
</reference>


<reference anchor="Pollard78" >
  <front>
    <title>Monte Carlo methods for index computation $({\rm mod}\ p)$</title>
    <author initials="J." surname="Pollard" fullname="J. M. Pollard">
      <organization></organization>
    </author>
    <date year="1978" month="September"/>
  </front>
  <seriesInfo name="Mathematics of Computation" value="Vol. 32, pp. 918-918"/>
  <seriesInfo name="DOI" value="10.1090/s0025-5718-1978-0491431-9"/>
</reference>

<reference anchor="HR83" >
  <front>
    <title>Fast Computation of Discrete Logarithms in GF (q)</title>
    <author initials="M." surname="Hellman" fullname="Martin E. Hellman">
      <organization></organization>
    </author>
    <author initials="J." surname="Reyneri" fullname="Justin M. Reyneri">
      <organization></organization>
    </author>
    <date year="1983"/>
  </front>
  <seriesInfo name="Advances in Cryptology" value="pp. 3-13"/>
  <seriesInfo name="DOI" value="10.1007/978-1-4757-0602-4_1"/>
</reference>



<reference  anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>


<reference anchor="mcl" target="https://github.com/herumi/mcl">
  <front>
    <title>mcl - A portable and fast pairing-based cryptography library</title>
    <author initials="S." surname="Mitsunari">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="BLS12-381" target="https://electriccoin.co/blog/new-snark-curve/">
  <front>
    <title>BLS12-381: New zk-SNARK Elliptic Curve Construction</title>
    <author initials="S." surname="Bowe">
      <organization></organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="NCCG" target="https://www.nccgroup.trust/us/our-research/zcash-overwinter-consensus-and-sapling-cryptography-review/">
  <front>
    <title>Zcash Overwinter Consensus and Sapling Cryptography Review</title>
    <author >
      <organization>NCC Group</organization>
    </author>
    <date />
  </front>
</reference>
<reference anchor="ISOIEC15946-5" >
  <front>
    <title>ISO/IEC 15946-5:2017</title>
    <author >
      <organization>ISO/IEC</organization>
    </author>
    <date year="2017"/>
  </front>
  <seriesInfo name="ISO/IEC" value="Information technology -- Security techniques -- Cryptographic techniques based on elliptic curves -- Part 5: Elliptic curve generation"/>
</reference>
<reference anchor="MIRACL" target="https://github.com/miracl/MIRACL">
  <front>
    <title>MIRACL Cryptographic SDK</title>
    <author >
      <organization>MIRACL Ltd.</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="libsnark" target="https://github.com/zcash/libsnark">
  <front>
    <title>libsnark: a C++ library for zkSNARK proofs</title>
    <author >
      <organization>SCIPR Lab</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="zkcrypto" target="https://github.com/zkcrypto/pairing">
  <front>
    <title>zkcrypto - Pairing-friendly elliptic curve library</title>
    <author >
      <organization>zkcrypto</organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="CIRCL" target="https://github.com/cloudflare/circl">
  <front>
    <title>CIRCL: Cloudflare Interoperable, Reusable Cryptographic Library</title>
    <author >
      <organization>Cloudflare</organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="go-bls" target="https://godoc.org/github.com/prysmaticlabs/go-bls">
  <front>
    <title>go-bls - Go wrapper for a BLS12-381 Signature Aggregation implementation in C++</title>
    <author >
      <organization>Prysmatic Labs</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="PBC" target="https://crypto.stanford.edu/pbc/">
  <front>
    <title>PBC Library - The Pairing-Based Cryptography Library</title>
    <author initials="B." surname="Lynn">
      <organization></organization>
    </author>
    <date year="2006"/>
  </front>
</reference>
<reference anchor="RELIC" target="https://github.com/relic-toolkit/relic">
  <front>
    <title>RELIC is an Efficient LIbrary for Cryptography</title>
    <author initials="C.P.L." surname="Gouvea">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="TEPLA" target="http://www.cipher.risk.tsukuba.ac.jp/tepla/index_e.html">
  <front>
    <title>TEPLA: University of Tsukuba Elliptic Curve and Pairing Library</title>
    <author >
      <organization>University of Tsukuba</organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="AMCL" target="https://github.com/apache/incubator-milagro-crypto">
  <front>
    <title>The Apache Milagro Cryptographic Library (AMCL)</title>
    <author >
      <organization>The Apache Software Foundation</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Intel-IPP" target="https://software.intel.com/en-us/ipp-crypto-reference-arithmetic-of-the-group-of-elliptic-curve-points">
  <front>
    <title>Developer Reference for Intel Integrated Performance Primitives Cryptography 2019</title>
    <author >
      <organization>Intel Corporation</organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="BLS48" target="https://github.com/mk-math-kyushu/bls48">
  <front>
    <title>bls48 - C++ library for Optimal Ate Pairing on BLS48</title>
    <author >
      <organization>Kyushu University</organization>
    </author>
    <date year="2017"/>
  </front>
</reference>


    </references>


<section anchor="comp_pairing" title="Computing Optimal Ate Pairing">

<t>Before presenting the computation of optimal Ate pairing e(P, Q) 
satisfying the properties shown in <xref target="pairing"/>, 
we give subfunctions used for pairing computation.</t>

<t>The following algorithm Line_Function shows the computation of the line function.
It takes A = (A[1], A[2]), B = (B[1], B[2]) in G_2 
and P = ((P[1], P[2])) in G_1 as input and outputs an element of G_T.</t>

<figure><artwork><![CDATA[
    if (A = B) then
        l := (3 * A[1]^2) / (2 * A[2]);
    else if (A = -B) then
        return P[1] - A[1];
    else
        l := (B[2] - A[2]) / (B[1] - A[1]);
    end if;
    return (l * (P[1] -A[1]) + A[2] -P[2]);
]]></artwork></figure>

<t>When implementing the line function, implementers should consider the isomorphism of E and its twisted curve E’ so that one can reduce the computational cost of operations in G_2. We note that the function Line_function does not consider such isomorphism.</t>

<t>Computation of optimal Ate pairing for BN curves uses Frobenius map.
Let a Frobenius map pi for a point Q = (x, y) over E’ be pi(p, Q) = (x^p, y^p).</t>

<section anchor="optimal-ate-pairings-over-barreto-naehrig-curves" title="Optimal Ate Pairings over Barreto-Naehrig Curves">

<t>Let c = 6 * t + 2 for a parameter t and c_0, c_1, … , c_L in {-1,0,1} such that the sum of c_i * 2^i (i = 0, 1, …, L) equals to c.</t>

<t>The following algorithm shows the computation of optimal Ate pairing over Barreto-Naehrig curves.
It takes P in G_1, Q in G_2, an integer c, c_0, …,c_L in {-1,0,1} such that the sum of c_i * 2^i (i = 0, 1, …, L) equals to c, and an order r as input, and outputs e(P, Q).</t>

<figure><artwork><![CDATA[
    f := 1; T := Q;
    if (c_L = -1)
        T := -T;
    end if
    for i = L-1 to 0
        f := f^2 * Line_function(T, T, P); T := 2 * T;
        if (c_i = 1 | c_i = -1)
            f := f * Line_function(T, c_i * Q); T := T + c_i * Q;
        end if
    end for
    Q_1 := pi(p, Q); Q_2 := pi(p, Q_1);
    f := f * Line_function(T, Q_1, P); T := T + Q_1;
    f := f * Line_function(T, -Q_2, P);
    f := f^{(p^k - 1) / r}
    return f;
]]></artwork></figure>

</section>
<section anchor="optimal-ate-pairings-over-barreto-lynn-scott-curves" title="Optimal Ate Pairings over Barreto-Lynn-Scott Curves">

<t>Let c = t for a parameter t and c_0, c_1, … , c_L in {-1,0,1} such that the sum of c_i * 2^i (i = 0, 1, …, L) equals to c.
The following algorithm shows the computation of optimal Ate pairing over Barreto-Lynn-Scott curves.
It takes P in G_1, Q in G_2, a parameter c, c_0, c_1, …, c_L in {-1,0,1} such that the sum of c_i * 2^i (i = 0, 1, …, L), 
and an order r as input, and outputs e(P, Q).</t>

<figure><artwork><![CDATA[
    f := 1; T := Q;
    if (c_L = -1)
        T := -T;
    end if
    for i = L-1 to 0
        f := f^2 * Line_function(T, T, P); T := 2 * T;
        if (c_i = 1 | c_i = -1)
            f := f * Line_function(T, c_i * Q, P); T := T + c_i * Q;
        end if
    end for
    f := f^{(p^k - 1) / r};
    return f;
]]></artwork></figure>

</section>
</section>
<section anchor="test-vectors-of-optimal-ate-pairing" title="Test Vectors of Optimal Ate Pairing">

<t>We provide test vectors for Optimal Ate Pairing e(P, Q) given in <xref target="comp_pairing"/> for the curves BN462, BLS12-381 and BLS48-581 given in <xref target="secure_params"/>.
Here, the inputs P = (x, y) and Q = (x’, y’) are the corresponding base points BP and BP’ given in <xref target="secure_params"/>.</t>

<t>For BN462 and BLS12-381, Q = (x’, y’) is given by</t>

<figure><artwork><![CDATA[
    x' = x'_0 + x'_1 * u and
    y' = y'_0 + y'_1 * u,
]]></artwork></figure>

<t>where u is a indeterminate and x’_0, x’_1, y’_0, y’_1 are elements of F_p.</t>

<t>For BLS48-581, Q = (x’, y’) is given by</t>

<figure><artwork><![CDATA[
    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 and 
    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,
]]></artwork></figure>

<t>where u, v and w are indeterminates and x’_0, …, x’_7 and y’_0, …, y’_7 are elements of F_p.
The representation of Q = (x’, y’) given below is followed by <xref target="I-D.draft-lwig-curve-representations"/>.</t>

<t>BN462:</t>

<t><list style="hanging">
  <t hangText='Input x value:'>
      0x21a6d67ef250191fadba34a0a30160b9ac9264b6f95f63b3edbec3cf4b2e689db1bbb4e69a416a0b1e79239c0372e5cd70113c98d91f36b6980d
  </t>
  <t hangText='Input y value:'>
      0x0118ea0460f7f7abb82b33676a7432a490eeda842cccfa7d788c659650426e6af77df11b8ae40eb80f475432c66600622ecaa8a5734d36fb03de
  </t>
  <t hangText='Input x’_0 value:'>
      0x0257ccc85b58dda0dfb38e3a8cbdc5482e0337e7c1cd96ed61c913820408208f9ad2699bad92e0032ae1f0aa6a8b48807695468e3d934ae1e4df
  </t>
  <t hangText='Input x’_1 value:'>
      0x1d2e4343e8599102af8edca849566ba3c98e2a354730cbed9176884058b18134dd86bae555b783718f50af8b59bf7e850e9b73108ba6aa8cd283
  </t>
  <t hangText='Input y’_0 value:'>
      0x0a0650439da22c1979517427a20809eca035634706e23c3fa7a6bb42fe810f1399a1f41c9ddae32e03695a140e7b11d7c3376e5b68df0db7154e
  </t>
  <t hangText='Input y’_1 value:'>
      0x073ef0cbd438cbe0172c8ae37306324d44d5e6b0c69ac57b393f1ab370fd725cc647692444a04ef87387aa68d53743493b9eba14cc552ca2a93a
  </t>

<!-- added e0 - e11 -->
  <t hangText='e_0:'>
      0x0cf7f0f2e01610804272f4a7a24014ac085543d787c8f8bf07059f93f87ba7e2a4ac77835d4ff10e78669be39cd23cc3a659c093dbe3b9647e8c
  </t>
  <t hangText='e_1:'>
      0x00ef2c737515694ee5b85051e39970f24e27ca278847c7cfa709b0df408b830b3763b1b001f1194445b62d6c093fb6f77e43e369edefb1200389
  </t>
  <t hangText='e_2:'>
      0x04d685b29fd2b8faedacd36873f24a06158742bb2328740f93827934592d6f1723e0772bb9ccd3025f88dc457fc4f77dfef76104ff43cd430bf7
  </t>
  <t hangText='e_3:'>
      0x090067ef2892de0c48ee49cbe4ff1f835286c700c8d191574cb424019de11142b3c722cc5083a71912411c4a1f61c00d1e8f14f545348eb7462c
  </t>
  <t hangText='e_4:'>
      0x1437603b60dce235a090c43f5147d9c03bd63081c8bb1ffa7d8a2c31d673230860bb3dfe4ca85581f7459204ef755f63cba1fbd6a4436f10ba0e
  </t>
  <t hangText='e_5:'>
      0x13191b1110d13650bf8e76b356fe776eb9d7a03fe33f82e3fe5732071f305d201843238cc96fd0e892bc61701e1844faa8e33446f87c6e29e75f
  </t>
  <t hangText='e_6:'>
      0x07b1ce375c0191c786bb184cc9c08a6ae5a569dd7586f75d6d2de2b2f075787ee5082d44ca4b8009b3285ecae5fa521e23be76e6a08f17fa5cc8
  </t>
  <t hangText='e_7:'>
      0x05b64add5e49574b124a02d85f508c8d2d37993ae4c370a9cda89a100cdb5e1d441b57768dbc68429ffae243c0c57fe5ab0a3ee4c6f2d9d34714
  </t>
  <t hangText='e_8:'>
      0x0fd9a3271854a2b4542b42c55916e1faf7a8b87a7d10907179ac7073f6a1de044906ffaf4760d11c8f92df3e50251e39ce92c700a12e77d0adf3
  </t>
  <t hangText='e_9:'>
      0x17fa0c7fa60c9a6d4d8bb9897991efd087899edc776f33743db921a689720c82257ee3c788e8160c112f18e841a3dd9a79a6f8782f771d542ee5
  </t>
  <t hangText='e_10:'>
      0x0c901397a62bb185a8f9cf336e28cfb0f354e2313f99c538cdceedf8b8aa22c23b896201170fc915690f79f6ba75581f1b76055cd89b7182041c
  </t>
  <t hangText='e_11:'>
      0x20f27fde93cee94ca4bf9ded1b1378c1b0d80439eeb1d0c8daef30db0037104a5e32a2ccc94fa1860a95e39a93ba51187b45f4c2c50c16482322
  </t>

</list></t>

<t>BLS12-381:</t>

<t><list style="hanging">
  <t hangText='Input x value:'>
      0x17f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb
  </t>
  <t hangText='Input y value:'>
      0x08b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1
  </t>
  <t hangText='Input x’_0 value:'>
      0x024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb8
  </t>
  <t hangText='Input x’_1 value:'>
      0x13e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e
  </t>
  <t hangText='Input y’_0 value:'>
      0x0ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801
  </t>
  <t hangText='Input y’_1 value:'>
      0x0606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be
  </t>

<!-- added e0 - e11 -->

  <t hangText='e_0:'>
      0x11619b45f61edfe3b47a15fac19442526ff489dcda25e59121d9931438907dfd448299a87dde3a649bdba96e84d54558
  </t>
  <t hangText='e_1:'>
      0x153ce14a76a53e205ba8f275ef1137c56a566f638b52d34ba3bf3bf22f277d70f76316218c0dfd583a394b8448d2be7f
  </t>
  <t hangText='e_2:'>
      0x095668fb4a02fe930ed44767834c915b283b1c6ca98c047bd4c272e9ac3f3ba6ff0b05a93e59c71fba77bce995f04692
  </t>
  <t hangText='e_3:'>
      0x16deedaa683124fe7260085184d88f7d036b86f53bb5b7f1fc5e248814782065413e7d958d17960109ea006b2afdeb5f
  </t>
  <t hangText='e_4:'>
      0x09c92cf02f3cd3d2f9d34bc44eee0dd50314ed44ca5d30ce6a9ec0539be7a86b121edc61839ccc908c4bdde256cd6048
  </t>
  <t hangText='e_5:'>
      0x111061f398efc2a97ff825b04d21089e24fd8b93a47e41e60eae7e9b2a38d54fa4dedced0811c34ce528781ab9e929c7
  </t>
  <t hangText='e_6:'>
      0x01ecfcf31c86257ab00b4709c33f1c9c4e007659dd5ffc4a735192167ce197058cfb4c94225e7f1b6c26ad9ba68f63bc
  </t>
  <t hangText='e_7:'>
      0x08890726743a1f94a8193a166800b7787744a8ad8e2f9365db76863e894b7a11d83f90d873567e9d645ccf725b32d26f
  </t>
  <t hangText='e_8:'>
      0x0e61c752414ca5dfd258e9606bac08daec29b3e2c57062669556954fb227d3f1260eedf25446a086b0844bcd43646c10
  </t>
  <t hangText='e_9:'>
      0x0fe63f185f56dd29150fc498bbeea78969e7e783043620db33f75a05a0a2ce5c442beaff9da195ff15164c00ab66bdde
  </t>
  <t hangText='e_10:'>
      0x10900338a92ed0b47af211636f7cfdec717b7ee43900eee9b5fc24f0000c5874d4801372db478987691c566a8c474978
  </t>
  <t hangText='e_11:'>
      0x1454814f3085f0e6602247671bc408bbce2007201536818c901dbd4d2095dd86c1ec8b888e59611f60a301af7776be3d
  </t>
  
</list></t>

<t>BLS48-581:</t>

 <t><list style="hanging">
  <t hangText='Input x value:'>
      0x02af59b7ac340f2baf2b73df1e93f860de3f257e0e86868cf61abdbaedffb9f7544550546a9df6f9645847665d859236ebdbc57db368b11786cb74da5d3a1e6d8c3bce8732315af640
  </t>
  <t hangText='Input y value:'>
      0x0cefda44f6531f91f86b3a2d1fb398a488a553c9efeb8a52e991279dd41b720ef7bb7beffb98aee53e80f678584c3ef22f487f77c2876d1b2e35f37aef7b926b576dbb5de3e2587a70
  </t>

<!-- x' and y' -->
  <t hangText='x’_0:'>
    0x05d615d9a7871e4a38237fa45a2775debabbefc70344dbccb7de64db3a2ef156c46ff79baad1a8c42281a63ca0612f400503004d80491f510317b79766322154dec34fd0b4ace8bfab
  </t>
  <t hangText='x’_1:'>
    0x07c4973ece2258512069b0e86abc07e8b22bb6d980e1623e9526f6da12307f4e1c3943a00abfedf16214a76affa62504f0c3c7630d979630ffd75556a01afa143f1669b36676b47c57
  </t>
  <t hangText='x’_2:'>
    0x01fccc70198f1334e1b2ea1853ad83bc73a8a6ca9ae237ca7a6d6957ccbab5ab6860161c1dbd19242ffae766f0d2a6d55f028cbdfbb879d5fea8ef4cded6b3f0b46488156ca55a3e6a
  </t>
  <t hangText='x’_3:'>
    0x0be2218c25ceb6185c78d8012954d4bfe8f5985ac62f3e5821b7b92a393f8be0cc218a95f63e1c776e6ec143b1b279b9468c31c5257c200ca52310b8cb4e80bc3f09a7033cbb7feafe
  </t>
  <t hangText='x’_4:'>
    0x038b91c600b35913a3c598e4caa9dd63007c675d0b1642b5675ff0e7c5805386699981f9e48199d5ac10b2ef492ae589274fad55fc1889aa80c65b5f746c9d4cbb739c3a1c53f8cce5
  </t>
  <t hangText='x’_5:'>
    0x0c96c7797eb0738603f1311e4ecda088f7b8f35dcef0977a3d1a58677bb037418181df63835d28997eb57b40b9c0b15dd7595a9f177612f097fc7960910fce3370f2004d914a3c093a
  </t>
  <t hangText='x’_6:'>
    0x0b9b7951c6061ee3f0197a498908aee660dea41b39d13852b6db908ba2c0b7a449cef11f293b13ced0fd0caa5efcf3432aad1cbe4324c22d63334b5b0e205c3354e41607e60750e057
  </t>
  <t hangText='x’_7:'>
    0x0827d5c22fb2bdec5282624c4f4aaa2b1e5d7a9defaf47b5211cf741719728a7f9f8cfca93f29cff364a7190b7e2b0d4585479bd6aebf9fc44e56af2fc9e97c3f84e19da00fbc6ae34
  </t>

  <t hangText='y’_0:'>
    0x00eb53356c375b5dfa497216452f3024b918b4238059a577e6f3b39ebfc435faab0906235afa27748d90f7336d8ae5163c1599abf77eea6d659045012ab12c0ff323edd3fe4d2d7971
  </t>
  <t hangText='y’_1:'>
    0x0284dc75979e0ff144da6531815fcadc2b75a422ba325e6fba01d72964732fcbf3afb096b243b1f192c5c3d1892ab24e1dd212fa097d760e2e588b423525ffc7b111471db936cd5665
  </t>
  <t hangText='y’_2:'>
    0x0b36a201dd008523e421efb70367669ef2c2fc5030216d5b119d3a480d370514475f7d5c99d0e90411515536ca3295e5e2f0c1d35d51a652269cbc7c46fc3b8fde68332a526a2a8474
  </t>
  <t hangText='y’_3:'>
    0x0aec25a4621edc0688223fbbd478762b1c2cded3360dcee23dd8b0e710e122d2742c89b224333fa40dced2817742770ba10d67bda503ee5e578fb3d8b8a1e5337316213da92841589d
  </t>
  <t hangText='y’_4:'>
    0x0d209d5a223a9c46916503fa5a88325a2554dc541b43dd93b5a959805f1129857ed85c77fa238cdce8a1e2ca4e512b64f59f430135945d137b08857fdddfcf7a43f47831f982e50137
  </t>
  <t hangText='y’_5:'>
    0x07d0d03745736b7a513d339d5ad537b90421ad66eb16722b589d82e2055ab7504fa83420e8c270841f6824f47c180d139e3aafc198caa72b679da59ed8226cf3a594eedc58cf90bee4
  </t>
  <t hangText='y’_6:'>
    0x0896767811be65ea25c2d05dfdd17af8a006f364fc0841b064155f14e4c819a6df98f425ae3a2864f22c1fab8c74b2618b5bb40fa639f53dccc9e884017d9aa62b3d41faeafeb23986
  </t>
  <t hangText='y’_7:'>
    0x035e2524ff89029d393a5c07e84f981b5e068f1406be8e50c87549b6ef8eca9a9533a3f8e69c31e97e1ad0333ec719205417300d8c4ab33f748e5ac66e84069c55d667ffcb732718b6
  </t>


<!-- added e0 - e47 -->

  <t hangText='e_0:'>
      0x0e26c3fcb8ef67417814098de5111ffcccc1d003d15b367bad07cef2291a93d31db03e3f03376f3beae2bd877bcfc22a25dc51016eda1ab56ee3033bc4b4fec5962f02dffb3af5e38e
  </t>
  <t hangText='e_1:'>
      0x069061b8047279aa5c2d25cdf676ddf34eddbc8ec2ec0f03614886fa828e1fc066b26d35744c0c38271843aa4fb617b57fa9eb4bd256d17367914159fc18b10a1085cb626e5bedb145
  </t>
  <t hangText='e_2:'>
      0x02b9bece645fbf9d8f97025a1545359f6fe3ffab3cd57094f862f7fb9ca01c88705c26675bcc723878e943da6b56ce25d063381fcd2a292e0e7501fe572744184fb4ab4ca071a04281
  </t>
  <t hangText='e_3:'>
      0x0080d267bf036c1e61d7fc73905e8c630b97aa05ef3266c82e7a111072c0d2056baa8137fba111c9650dfb18cb1f43363041e202e3192fced29d2b0501c882543fb370a56bfdc2435b
  </t>
  <t hangText='e_4:'>
      0x03c6b4c12f338f9401e6a493a405b33e64389338db8c5e592a8dd79eac7720dd83dd6b0c189eeda20809160cd57cdf3e2edc82db15f553c1f6c953ea27114cb6bd8a38e273f407dae0
  </t>
  <t hangText='e_5:'>
      0x016e46224f28bfd8833f76ac29ee6e406a9da1bde55f5e82b3bd977897a9104f18b9ee41ea9af7d4183d895102950a12ce9975669db07924e1b432d9680f5ce7e5c67ed68f381eba45
  </t>
  <t hangText='e_6:'>
      0x008ddce7a4a1b94be5df3ceea56bef0077dcdde86d579938a50933a47296d337b7629934128e2457e24142b0eeaa978fd8e70986d7dd51fccbbeb8a1933434fec4f5bc538de2646e90
  </t>
  <t hangText='e_7:'>
      0x060ef6eae55728e40bd4628265218b24b38cdd434968c14bfefb87f0dcbfc76cc473ae2dc0cac6e69dfdf90951175178dc75b9cc08320fcde187aa58ea047a2ee00b1968650eec2791
  </t>
  <t hangText='e_8:'>
      0x0c3943636876fd4f9393414099a746f84b2633dfb7c36ba6512a0b48e66dcb2e409f1b9e150e36b0b4311165810a3c721525f0d43a021f090e6a27577b42c7a57bed3327edb98ba8f8
  </t>
  <t hangText='e_9:'>
      0x02d31eb8be0d923cac2a8eb6a07556c8951d849ec53c2848ee78c5eed40262eb21822527a8555b071f1cd080e049e5e7ebfe2541d5b42c1e414341694d6f16d287e4a8d28359c2d2f9
  </t>
  <t hangText='e_10:'>
      0x07f19673c5580d6a10d09a032397c5d425c3a99ff1dd0abe5bec40a0d47a6b8daabb22edb6b06dd8691950b8f23faefcdd80c45aa3817a840018965941f4247f9f97233a84f58b262e
  </t>
  <t hangText='e_11:'>
      0x0d3fe01f0c114915c3bdf8089377780076c1685302279fd9ab12d07477aac03b69291652e9f179baa0a99c38aa8851c1d25ffdb4ded2c8fe8b30338c14428607d6d822610d41f51372
  </t>
  <t hangText='e_12:'>
      0x0662eefd5fab9509aed968866b68cff3bc5d48ecc8ac6867c212a2d82cee5a689a3c9c67f1d611adac7268dc8b06471c0598f7016ca3d1c01649dda4b43531cffc4eb41e691e27f2eb
  </t>
  <t hangText='e_13:'>
      0x0aad8f4a8cfdca8de0985070304fe4f4d32f99b01d4ea50d9f7cd2abdc0aeea99311a36ec6ed18208642cef9e09b96795b27c42a5a744a7b01a617a91d9fb7623d636640d61a6596ec
  </t>
  <t hangText='e_14:'>
      0x0ffcf21d641fd9c6a641a749d80cab1bcad4b34ee97567d905ed9d5cfb74e9aef19674e2eb6ce3dfb706aa814d4a228db4fcd707e571259435393a27cac68b59a1b690ae8cde7a94c3
  </t>
  <t hangText='e_15:'>
      0x0cbe92a53151790cece4a86f91e9b31644a86fc4c954e5fa04e707beb69fc60a858fed8ebd53e4cfd51546d5c0732331071c358d721ee601bfd3847e0e904101c62822dd2e4c7f8e5c
  </t>
  <t hangText='e_16:'>
      0x0202db83b1ff33016679b6cfc8931deea6df1485c894dcd113bacf564411519a42026b5fda4e16262674dcb3f089cd7d552f8089a1fec93e3db6bca43788cdb06fc41baaa5c5098667
  </t>
  <t hangText='e_17:'>
      0x070a617ed131b857f5b74b625c4ef70cc567f619defb5f2ab67534a1a8aa72975fc4248ac8551ce02b68801703971a2cf1cb934c9c354cadd5cfc4575cde8dbde6122bd54826a9b3e9
  </t>
  <t hangText='e_18:'>
      0x070e1ebce457c141417f88423127b7a7321424f64119d5089d883cb953283ee4e1f2e01ffa7b903fe7a94af4bb1acb02ca6a36678e41506879069cee11c9dcf6a080b6a4a7c7f21dc9
  </t>
  <t hangText='e_19:'>
      0x058a06be5a36c6148d8a1287ee7f0e725453fa1bb05cf77239f235b417127e370cfa4f88e61a23ea16df3c45d29c203d04d09782b39e9b4037c0c4ac8e8653e7c533ad752a640b233e
  </t>
  <t hangText='e_20:'>
      0x0dfdfaaeb9349cf18d21b92ad68f8a7ecc509c35fcd4b8abeb93be7a204ac871f2195180206a2c340fccb69dbc30b9410ed0b122308a8fc75141f673ae5ec82b6a45fc2d664409c6b6
  </t>
  <t hangText='e_21:'>
      0x0d06c8adfdd81275da2a0ce375b8df9199f3d359e8cf50064a3dc10a592417124a3b705b05a7ffe78e20f935a08868ecf3fc5aba0ace7ce4497bb59085ca277c16b3d53dd7dae5c857
  </t>
  <t hangText='e_22:'>
      0x0708effd28c4ae21b6969cb9bdd0c27f8a3e341798b6f6d4baf27be259b4a47688b50cb68a69a917a4a1faf56cec93f69ac416512c32e9d5e69bd8836b6c2ba9c6889d507ad571dbc4
  </t>
  <t hangText='e_23:'>
      0x09da7c7aa48ce571f8ece74b98431b14ae6fb4a53ae979cd6b2e82320e8d25a0ece1ca1563aa5aa6926e7d608358af8399534f6b00788e95e37ef1b549f43a58ad250a71f0b2fdb2bf
  </t>
  <t hangText='e_24:'>
      0x0a7150a14471994833d89f41daeaa999dfc24a9968d4e33d88ed9e9f07aa2432c53e486ba6e3b6e4f4b8d9c989010a375935c06e4b8d6c31239fad6a61e2647b84a0e3f76e57005ff7
  </t>
  <t hangText='e_25:'>
      0x084696f31ff27889d4dccdc4967964a5387a5ae071ad391c5723c9034f16c2557915ada07ec68f18672b5b2107f785c15ddf9697046dc633b5a23cc0e442d28ef6eea9915d0638d4d8
  </t>
  <t hangText='e_26:'>
      0x0398e76e3d2202f999ac0f73e0099fe4e0fe2de9d223e78fc65c56e209cdf48f0d1ad8f6093e924ce5f0c93437c11212b7841de26f9067065b1898f48006bcc6f2ab8fa8e0b93f4ba4
  </t>
  <t hangText='e_27:'>
      0x06d683f556022368e7a633dc6fe319fd1d4fc0e07acff7c4d4177e83a911e73313e0ed980cd9197bd17ac45942a65d90e6cb9209ede7f36c10e009c9d337ee97c4068db40e34d0e361
  </t>
  <t hangText='e_28:'>
      0x0d764075344b70818f91b13ee445fd8c1587d1c0664002180bbac9a396ad4a8dc1e695b0c4267df4a09081c1e5c256c53fd49a73ffc817e65217a44fc0b20ef5ee92b28d4bc3e38576
  </t>
  <t hangText='e_29:'>
      0x0aa6a32fdc4423b1c6d43e5104159bcd8e03a676d055d4496f7b1bc8761164a2908a3ff0e4c4d1f4362015c14824927011e2909531b8d87ee0acd676e7221a1ca1c21a33e2cf87dc51
  </t>
  <t hangText='e_30:'>
      0x1147719959ac8eeab3fc913539784f1f947df47066b6c0c1beafecdb5fa784c3be9de5ab282a678a2a0cbef8714141a6c8aaa76500819a896b46af20509953495e2a85eff58348b38d
  </t>
  <t hangText='e_31:'>
      0x11a377bcebd3c12702bb34044f06f8870ca712fb5caa6d30c48ace96898fcbcddbcf31f331c9e524684c02c90db7f30b9fc470d6e651a7e8b1f684383f3705d7a47a1b4fe463d623c8
  </t>
  <t hangText='e_32:'>
      0x0b8b4511f451ba2cc58dc28e56d5e1d0a8f557ecb242f4d994a627e07cf3fa44e6d83cb907deacf303d2f761810b5d943b46c4383e1435ec23fec196a70e33946173c78be3c75dfc83
  </t>
  <t hangText='e_33:'>
      0x090962d632ee2a57ce4208052ce47a9f76ea0fdad724b7256bb07f3944e9639a981d3431087241e30ae9bf5e2ea32af323ce7ed195d383b749cb25bc09f678d385a49a0c09f6d9efca
  </t>
  <t hangText='e_34:'>
      0x0931c7befc80acd185491c68af886fa8ee39c21ed3ebd743b9168ae3b298df485bfdc75b94f0b21aecd8dca941dfc6d1566cc70dc648e6ccc73e4cbf2a1ac83c8294d447c66e74784d
  </t>
  <t hangText='e_35:'>
      0x020ac007bf6c76ec827d53647058aca48896916269c6a2016b8c06f0130901c8975779f1672e581e2dfdbcf504e96ecf6801d0d39aad35cf79fbe7fe193c6c882c15bce593223f0c7c
  </t>
  <t hangText='e_36:'>
      0x0c0aed0d890c3b0b673bf4981398dcbf0d15d36af6347a39599f3a22584184828f78f91bbbbd08124a97672963ec313ff142c456ec1a2fc3909fd4429fd699d827d48777d3b0e0e699
  </t>
  <t hangText='e_37:'>
      0x0ef7799241a1ba6baaa8740d5667a1ace50fb8e63accc3bc30dc07b11d78dc545b68910c027489a0d842d1ba3ac406197881361a18b9fe337ff22d730fa44afabb9f801f759086c8e4
  </t>
  <t hangText='e_38:'>
      0x016663c940d062f4057257c8f4fb9b35e82541717a34582dd7d55b41ebadf40d486ed74570043b2a3c4de29859fdeae9b6b456cb33bb401ecf38f9685646692300517e9b035d6665fc
  </t>
  <t hangText='e_39:'>
      0x1184a79510edf25e3bd2dc793a5082fa0fed0d559fa14a5ce9ffca4c61f17196e1ffbb84326272e0d079368e9a735be1d05ec80c20dc6198b50a22a765defdc151d437335f1309aced
  </t>
  <t hangText='e_40:'>
      0x120e47a747d942a593d202707c936dafa6fed489967dd94e48f317fd3c881b1041e3b6bbf9e8031d44e39c1ab5ae41e487eac9acd90e869129c38a8e6c97cf55d6666d22299951f91a
  </t>
  <t hangText='e_41:'>
      0x026b6e374108ecb2fe8d557087f40ab7bac8c5af0644a655271765d57ad71742aa331326d871610a8c4c30ccf5d8adbeec23cdff20d9502a5005fce2593caf0682c82e4873b89d6d71
  </t>
  <t hangText='e_42:'>
      0x041be63a2fa643e5a66faeb099a3440105c18dca58d51f74b3bf281da4e689b13f365273a2ed397e7b1c26bdd4daade710c30350318b0ae9a9b16882c29fe31ca3b884c92916d6d07a
  </t>
  <t hangText='e_43:'>
      0x124018a12f0f0af881e6765e9e81071acc56ebcddadcd107750bd8697440cc16f190a3595633bb8900e6829823866c5769f03a306f979a3e039e620d6d2f576793d36d840b168eeedd
  </t>
  <t hangText='e_44:'>
      0x0d422de4a83449c535b4b9ece586754c941548f15d50ada6740865be9c0b066788b6078727c7dee299acc15cbdcc7d51cdc5b17757c07d9a9146b01d2fdc7b8c562002da0f9084bde5
  </t>
  <t hangText='e_45:'>
      0x1119f6c5468bce2ec2b450858dc073fea4fb05b6e83dd20c55c9cf694cbcc57fc0effb1d33b9b5587852d0961c40ff114b7493361e4cfdff16e85fbce667869b6f7e9eb804bcec46db
  </t>
  <t hangText='e_46:'>
      0x061eaa8e9b0085364a61ea4f69c3516b6bf9f79f8c79d053e646ea637215cf6590203b275290872e3d7b258102dd0c0a4a310af3958165f2078ff9dc3ac9e995ce5413268d80974784
  </t>
  <t hangText='e_47:'>
      0x0add8d58e9ec0c9393eb8c4bc0b08174a6b421e15040ef558da58d241e5f906ad6ca2aa5de361421708a6b8ff6736efbac6b4688bf752259b4650595aa395c40d00f4417f180779985
  </t>

</list></t>
</section>


  </back>
</rfc>