<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-irtf-cfrg-curves-05" ipr="trust200902">
  <front>
    <title abbrev="cfrgcurve">Elliptic Curves for Security</title>

    <author fullname="Adam Langley" initials="A." surname="Langley">
      <organization>Google</organization>
      <address>
        <postal>
          <street>345 Spear St</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94105</code>
          <country>US</country>
        </postal>
        <email>agl@google.com</email>
      </address>
    </author>

    <author fullname="Mike Hamburg" initials="M." surname="Hamburg">
      <organization>Rambus Cryptography Research</organization>
      <address>
        <postal>
          <street>425 Market Street, 11th Floor</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94105</code>
          <country>US</country>
        </postal>
        <email>mike@shiftleft.org</email>
      </address>
    </author>

    <author fullname="Sean Turner" initials="S." surname="Turner">
      <organization>IECA, Inc.</organization>
      <address>
        <postal>
          <street>3057 Nutley Street</street>
          <street>Suite 106</street>
          <city>Fairfax</city>
          <region>VA</region>
          <code>22031</code>
          <country>US</country>
        </postal>
        <email>turners@ieca.com</email>
      </address>
    </author>

    <date month="August" year="2015" />

    <area>General</area>
    <workgroup>CFRG</workgroup>

    <keyword>elliptic curve</keyword>
    <keyword>cryptography</keyword>
    <keyword>ecc</keyword>

    <abstract>
      <t>This memo specifies two elliptic curves over prime fields that offer high practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Since the initial standardization of elliptic curve cryptography (ECC) in <xref target="SEC1"/> there has been significant progress related to both efficiency and security of curves and implementations. Notable examples are algorithms protected against certain side-channel attacks, various 'special' prime shapes that allow faster modular arithmetic, and a larger set of curve models from which to choose. There is also concern in the community regarding the generation and potential weaknesses of the curves defined by NIST <xref target="NIST"/>.</t>

      <t>This memo specifies two elliptic curves (curve25519 and curve448) that support constant-time, exception-free scalar multiplication that is resistant to a wide range of side-channel attacks, including timing and cache attacks. They are Montgomery curves (where y^2 = x^3 + Ax^2 + x) and thus have birationally equivalent Edwards versions. Edwards curves support the fastest (currently known) complete formulas for the elliptic-curve group operations, specifically the Edwards curve x^2 + y^2 = 1 + dx^2y^2 for primes p when p = 3 mod 4, and the twisted Edwards curve -x^2 + y^2 = 1 + dx^2y^2 when p = 1 mod 4. The maps to/from the Montgomery curves to their (twisted) Edwards equivalents are also given.</t>
    </section>

    <section title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section anchor="notation" title="Notation">
      <t>Throughout this document, the following notation is used:</t>

      <t>
        <list style="hanging">
          <t hangText="p">Denotes the prime number defining the underlying field.</t>
          <t hangText="GF(p)">The finite field with p elements.</t>
          <t hangText="A">An element in the finite field GF(p), not equal to -2 or 2.</t>
          <t hangText="d">An element in the finite field GF(p), not equal to 0 or 1.</t>
          <t hangText="P">A generator point defined over GF(p) of prime order.</t>
          <t hangText="X(P)">The x-coordinate of the elliptic curve point P on a (twisted) Edwards curve.</t>
          <t hangText="Y(P)">The y-coordinate of the elliptic curve point P on a (twisted) Edwards curve.</t>
          <t hangText="u, v">Coordinates on a Montgomery curve.</t>
          <t hangText="x, y">Coordinates on a (twisted) Edwards curve.</t>
        </list>
      </t>
    </section>

    <section anchor="curves" title="Recommended Curves">
      <section anchor="curve25519curve" title="Curve25519">
        <t>For the ~128-bit security level, the prime 2^255-19 is recommended for performance on a wide-range of architectures. This prime is congruent to 1 mod 4 and the derivation procedure in <xref target="generation"/> results in the following Montgomery curve v^2 = u^3 + A*u^2 + u, called <spanx style="verb">curve25519</spanx>:</t>

        <t>
          <list style="hanging">
            <t hangText="p">2^255-19</t>
            <t hangText="A">486662</t>
            <t hangText="order">2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed</t>
            <t hangText="cofactor">8</t>
            </list>
        </t>

        <t>The base point is u = 9, v = 14781619447589544791020593568409986887264606134616475288964881837755586237401.</t>

        <t>This curve is birationally equivalent to a twisted Edwards curve -x^2 + y^2 = 1 + d*x^2*y^2, called <spanx style="verb">edwards25519</spanx>, where:</t>

        <t>
          <list style="hanging">
            <t hangText="p">2^255-19</t>
            <t hangText="d">37095705934669439343138083508754565189542113879843219016388785533085940283555</t>
            <t hangText="order">2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed</t>
            <t hangText="cofactor">8</t>
            <t hangText="X(P)">15112221349535400772501151409588531511454012693041857206046113283949847762202</t>
            <t hangText="Y(P)">46316835694926478169428394003475163141307993866256225615783033603165251855960</t>
          </list>
        </t>

        <t>The birational maps are:</t>
        <figure align="center">
          <artwork align="left"><![CDATA[
  (u, v) = ((1+y)/(1-y), sqrt(-486664)*u/x)
  (x, y) = (sqrt(-486664)*u/v, (u-1)/(u+1)]]></artwork>
        </figure>

        <t>The Montgomery curve defined here is equal to the one defined in <xref target="curve25519"/> and the equivalent twisted Edwards curve is equal to the one defined in <xref target="ed25519"/>.</t>

        </section>
        <section anchor="curve448curve" title="Curve448">
          <t>For the ~224-bit security level, the prime 2^448-2^224-1 is recommended for performance on a wide-range of architectures. This prime is congruent to 3 mod 4 and the derivation procedure in <xref target="generation"/> results in the following Montgomery curve, called <spanx style="verb">curve448</spanx>:</t>

        <t>
          <list style="hanging">
            <t hangText="p">2^448-2^224-1</t>
            <t hangText="A">156326</t>
            <t hangText="order">2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d</t>
            <t hangText="cofactor">4</t>
          </list>
        </t>

        <t>The base point is u = 5, v =
          355293926785568175264127502063783334808976399387714271831880898435169088786967410002932673765864550910142774147268105838985595290606362.</t>

        <t>This curve is birationally equivalent to the Edwards curve x^2 + y^2 = 1 + d*x^2*y^2 where:</t>

        <t>
          <list style="hanging">
            <t hangText="p">2^448-2^224-1</t>
            <t hangText="d">611975850744529176160423220965553317543219696871016626328968936415087860042636474891785599283666020414768678979989378147065462815545017</t>
            <t hangText="order">2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d</t>
            <t hangText="cofactor">4</t>
            <t hangText="X(P)">345397493039729516374008604150537410266655260075183290216406970281645695073672344430481787759340633221708391583424041788924124567700732</t>
            <t hangText="Y(P)">363419362147803445274661903944002267176820680343659030140745099590306164083365386343198191849338272965044442230921818680526749009182718</t>
          </list>
        </t>

        <t>The birational maps are:</t>
        <figure align="center">
          <artwork align="left"><![CDATA[
  (u, v) = ((y-1)/(y+1), sqrt(156324)*u/x)
  (x, y) = (sqrt(156324)*u/v, (1+u)/(1-u)]]></artwork>
        </figure>

        <t>Both of those curves are also 4-isogenous to the following Edwards curve x^2 + y^2 = 1 + d*x^2*y^2, called <spanx style="verb">edwards448</spanx>, where:</t>

        <t>
          <list style="hanging">
            <t hangText="p">2^448-2^224-1</t>
            <t hangText="d">-39081</t>
            <t hangText="order">2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d</t>
            <t hangText="cofactor">4</t>
            <t hangText="X(P)">224580040295924300187604334099896036246789641632564134246125461686950415467406032909029192869357953282578032075146446173674602635247710</t>
            <t hangText="Y(P)">298819210078481492676017930443930673437544040154080242095928241372331506189835876003536878655418784733982303233503462500531545062832660</t>
          </list>
        </t>

        <t>The 4-isogeny maps between the Montgomery curve this the Edwards curve are:</t>
        <figure align="center">
          <artwork align="left"><![CDATA[
  (u, v) = (y^2/x^2, -(2 - x^2 - y^2)*y/x^3)
  (x, y) = (4*v*(u^2 - 1)/(u^4 - 2*u^2 + 4*v^2 + 1),
            (u^5 - 2*u^3 - 4*u*v^2 + u)/
            (u^5 - 2*u^2*v^2 - 2*u^3 - 2*v^2 + u))]]></artwork>
        </figure>

        <t>The curve <spanx style="verb">edwards448</spanx> defined here is also called "Goldilocks" and is equal to the one defined in <xref target="goldilocks"/>.</t>
      </section>
    </section>

    <section title="The X25519 and X448 functions">
      <t>The <spanx style="verb">X25519</spanx> and <spanx style="verb">X448</spanx> functions perform scalar multiplication on the Montgomery form of the above curves. (This is used when implementing Diffie-Hellman.) The functions take a scalar and a u-coordinate as inputs and produce a u-coordinate as output. Although the functions work internally with integers, the inputs and outputs are 32-byte or 56-byte strings and this specification defines their encoding.</t>

      <t>U-coordinates are elements of the underlying field GF(2^255-19) or GF(2^448-2^224-1) and are encoded as an array of bytes, u, in little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... + 256^n*u[n] is congruent to the value modulo p and u[n] is minimal. When receiving such an array, implementations of X25519 (but not X448) MUST mask the most-significant bit in the final byte. This is done to preserve compatibility with point formats which reserve the sign bit for use in other protocols and to increase resistance to implementation fingerprinting.</t>

      <t>Implementations MUST accept non-canonical values and process them as if they had been reduced modulo the field prime. The non-canonical values are 2^255-19 through 2^255-1 for X25519 and 2^448-2^224-1 through 2^448-1 for X448.</t>

      <t>The following functions implement this in Python, although the Python code is not intended to be performant nor side-channel free. Here the "bits" parameter should be set to 255 for X25519 and 448 for X448:</t>

      <figure align="center">
        <artwork align="left"><![CDATA[
def decodeLittleEndian(b, bits):
    return sum([b[i] << 8*i for i in range((bits+7)/8)])

def decodeUCoordinate(u, bits):
    u_list = [ord(b) for b in u]
    # Ignore any unused bits.
    if bits % 8:
        u_list[-1] &= (1<<(bits%8))-1
    return decodeLittleEndian(u_list, bits)

def encodeUCoordinate(u, bits):
    u = u % p
    return ''.join([chr((u >> 8*i) & 0xff) for i in range((bits+7)/8)])]]></artwork>
      </figure>

      <t>Scalars are assumed to be randomly generated bytes. For X25519, in order to decode 32 random bytes as an integer scalar, set the three least significant bits of the first byte and the most significant bit of the last to zero, set the second most significant bit of the last byte to 1 and, finally, decode as little-endian. This means that resulting integer is of the form 2^254 + 8 * {0, 1, ..., 2^(251) - 1}. Likewise, for X448, set the two least significant bits of the first byte to 0, and the most significant bit of the last byte to 1. This means that the resulting integer is of the form 2^447 + 4 * {0, 1, ..., 2^(445) - 1}.</t>

      <figure align="center">
        <artwork align="left"><![CDATA[
def decodeScalar25519(k):
    k_list = [ord(b) for b in k]
    k_list[0] &= 248
    k_list[31] &= 127
    k_list[31] |= 64
    return decodeLittleEndian(k_list, 255)

def decodeScalar448(k):
    k_list = [ord(b) for b in k]
    k_list[0] &= 252
    k_list[55] |= 128
    return decodeLittleEndian(k_list, 448)]]></artwork>
      </figure>

      <t>To implement the <spanx style="verb">X25519(k, u)</spanx> and <spanx style="verb">X448(k, u)</spanx> functions (where <spanx style="verb">k</spanx> is the scalar and <spanx style="verb">u</spanx> is the u-coordinate) first decode <spanx style="verb">k</spanx> and <spanx style="verb">u</spanx> and then perform the following procedure, which is taken from <xref target="curve25519"/> and based on formulas from <xref target="montgomery"/>. All calculations are performed in GF(p), i.e., they are performed modulo p. The constant a24 is (486662 - 2) / 4 = 121665 for curve25519/X25519 and (156326 - 2) / 4 = 39081 for curve448/X448.</t>

      <figure align="center">
        <artwork align="left"><![CDATA[
x_1 = u
x_2 = 1
z_2 = 0
x_3 = u
z_3 = 1
swap = 0

For t = bits-1 down to 0:
    k_t = (k >> t) & 1
    swap ^= k_t
    // Conditional swap; see text below.
    (x_2, x_3) = cswap(swap, x_2, x_3)
    (z_2, z_3) = cswap(swap, z_2, z_3)
    swap = k_t

    A = x_2 + z_2
    AA = A^2
    B = x_2 - z_2
    BB = B^2
    E = AA - BB
    C = x_3 + z_3
    D = x_3 - z_3
    DA = D * A
    CB = C * B
    x_3 = (DA + CB)^2
    z_3 = x_1 * (DA - CB)^2
    x_2 = AA * BB
    z_2 = E * (AA + a24 * E)

// Conditional swap; see text below.
(x_2, x_3) = cswap(swap, x_2, x_3)
(z_2, z_3) = cswap(swap, z_2, z_3)
Return x_2 * (z_2^(p - 2))]]></artwork>
      </figure>

      <t>(Note that these formulas are slightly different from Montgomery's original paper. Implementations are free to use any correct formulas.)</t>

      <t>Finally, encode the resulting value as 32 or 56 bytes in little-endian order. For X25519, the unused, most-significant bit MUST be zero.</t>

      <t>When implementing this procedure, due to the existence of side-channels in commodity hardware, it is important that the pattern of memory accesses and jumps not depend on the values of any of the bits of <spanx style="verb">k</spanx>. It is also important that the arithmetic used not leak information about the integers modulo p (such as having b*c be distinguishable from c*c).</t>

      <t>The cswap function SHOULD be implemented in constant time (i.e. independent of the <spanx style="verb">swap</spanx> argument). For example, this can be done as follows:</t>

      <figure align="center">
        <artwork align="left"><![CDATA[
cswap(swap, x_2, x_3):
      dummy = mask(swap) AND (x_2 XOR x_3)
      x_2 = x_2 XOR dummy
      x_3 = x_3 XOR dummy
      Return (x_2, x_3)]]></artwork>
      </figure>

      <t>Where <spanx style="verb">mask(swap)</spanx> is the all-1 or all-0 word of the same length as x_2 and x_3, computed, e.g., as mask(swap) = 0 - swap.</t>

      <section title="Test vectors">
        <t>Two types of tests are provided. The first is a pair of test vectors for each function that consist of expected outputs for the given inputs:</t>

        <figure align="center">
          <artwork align="left"><![CDATA[
X25519:

Input scalar:
  a546e36bf0527c9d3b16154b82465edd62144c0ac1fc5a18506a2244ba449ac4
Input scalar as a number (base 10):
  31029842492115040904895560451863089656
  472772604678260265531221036453811406496
Input U-coordinate:
  e6db6867583030db3594c1a424b15f7c726624ec26b3353b10a903a6d0ab1c4c
Input U-coordinate as a number:
  34426434033919594451155107781188821651
  316167215306631574996226621102155684838
Output U-coordinate:
  c3da55379de9c6908e94ea4df28d084f32eccf03491c71f754b4075577a28552

Input scalar:
  4b66e9d4d1b4673c5ad22691957d6af5c11b6421e0ea01d42ca4169e7918ba0d
Input scalar as a number (base 10):
  35156891815674817266734212754503633747
  128614016119564763269015315466259359304
Input U-coordinate:
  e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493
Input U-coordinate as a number:
  88838573511839298940907593866106493194
  17338800022198945255395922347792736741
Output U-coordinate:
  95cbde9476e8907d7aade45cb4b873f88b595a68799fa152e6f8f7647aac7957


X448:

Input scalar:
  3d262fddf9ec8e88495266fea19a34d28882acef045104d0d1aae121
  700a779c984c24f8cdd78fbff44943eba368f54b29259a4f1c600ad3
Input scalar as a number (base 10):
  5991891753738964027837560161452132561572308560850261299268914594686 \
  22403380588640249457727683869421921443004045221642549886377526240828
Input U-coordinate:
  06fce640fa3487bfda5f6cf2d5263f8aad88334cbd07437f020f08f9
  814dc031ddbdc38c19c6da2583fa5429db94ada18aa7a7fb4ef8a086
Input U-coordinate as a number:
  3822399108141073301162299612348993770314163652405713251483465559224 \
  38025162094455820962429142971339584360034337310079791515452463053830
Output U-coordinate:
  ce3e4ff95a60dc6697da1db1d85e6afbdf79b50a2412d7546d5f239f
  e14fbaadeb445fc66a01b0779d98223961111e21766282f73dd96b6f

Input scalar:
  203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5
  38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f
Input scalar as a number (base 10):
  6332543359069705927792594815348623723825251552520289610564040013321 \
  22152890562527156973881968934311400345568203929409663925541994577184
Input U-coordinate:
  0fbcc2f993cd56d3305b0b7d9e55d4c1a8fb5dbb52f8e9a1e9b6201b
  165d015894e56c4d3570bee52fe205e28a78b91cdfbde71ce8d157db
Input U-coordinate as a number:
  6227617977583254444629220684312341806495903900248112997616251537672 \
  28042600197997696167956134770744996690267634159427999832340166786063
Output U-coordinate:
  884a02576239ff7a2f2f63b2db6a9ff37047ac13568e1e30fe63c4a7
  ad1b3ee3a5700df34321d62077e63633c575c1c954514e99da7c179d]]></artwork>
        </figure>

        <t>The second type of test vector consists of the result of calling the function in question a specified number of times. Initially, set <spanx style="verb">k</spanx> and <spanx style="verb">u</spanx> to be the following values:</t>

        <figure align="center">
          <artwork align="left"><![CDATA[
For X25519:
  0900000000000000000000000000000000000000000000000000000000000000
For X448:
  05000000000000000000000000000000000000000000000000000000
  00000000000000000000000000000000000000000000000000000000]]></artwork>
        </figure>

        <t>For each iteration, set <spanx style="verb">k</spanx> to be the result of calling the function and <spanx style="verb">u</spanx> to be the old value of <spanx style="verb">k</spanx>. The final result is the value left in <spanx style="verb">k</spanx>.</t>

        <figure align="center">
          <artwork align="left"><![CDATA[
X25519:

After one iteration:
    422c8e7a6227d7bca1350b3e2bb7279f7897b87bb6854b783c60e80311ae3079
After 1,000 iterations:
    684cf59ba83309552800ef566f2f4d3c1c3887c49360e3875f2eb94d99532c51
After 1,000,000 iterations:
    7c3911e0ab2586fd864497297e575e6f3bc601c0883c30df5f4dd2d24f665424


X448:

After one iteration:
    3f482c8a9f19b01e6c46ee9711d9dc14fd4bf67af30765c2ae2b846a
    4d23a8cd0db897086239492caf350b51f833868b9bc2b3bca9cf4113
After 1,000 iterations:
    aa3b4749d55b9daf1e5b00288826c467274ce3ebbdd5c17b975e09d4
    af6c67cf10d087202db88286e2b79fceea3ec353ef54faa26e219f38
After 1,000,000 iterations:
    077f453681caca3693198420bbe515cae0002472519b3e67661a7e89
    cab94695c8f4bcd66e61b9b9c946da8d524de3d69bd9d9d66b997e37]]></artwork>
        </figure>
      </section>
    </section>

    <section title="Diffie-Hellman">
      <section title="Curve25519">
        <t>The <spanx style="verb">X25519</spanx> function can be used in an elliptic-curve Diffie-Hellman (ECDH) protocol as follows:</t>

        <t>Alice generates 32 random bytes in f[0] to f[31] and transmits K_A = X25519(f, 9) to Bob, where 9 is the u-coordinate of the base point and is encoded as a byte with value 9, followed by 31 zero bytes.</t>

        <t>Bob similarly generates 32 random bytes in g[0] to g[31] and computes K_B = X25519(g, 9) and transmits it to Alice.</t>

        <t>Using their generated values and the received input, Alice computes X25519(f, K_B) and Bob computes X25519(g, K_A).</t>

        <t>Both now share K = X25519(f, X25519(g, 9)) = X25519(g, X25519(f, 9)) as a shared secret. Both MUST check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below). Alice and Bob can then use a key-derivation function that includes K, K_A and K_B to derive a key.</t>

        <t>The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with order dividing the co-factor, h, of the curve. This check is cheap and so MUST always be carried out. The check may be performed by ORing all the bytes together and checking whether the result is zero as this eliminates standard side-channels in software implementations.</t>

        <t>Test vector:</t>

        <figure align="center">
          <artwork align="left"><![CDATA[
Alice's private key, f:
  77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
Alice's public key, X25519(f, 9):
  8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a
Bob's private key, g:
  5dab087e624a8a4b79e17f8b83800ee66f3bb1292618b6fd1c2f8b27ff88e0eb
Bob's public key, X25519(g, 9):
  de9edb7d7b7dc1b4d35b61c2ece435373f8343c85b78674dadfc7e146f882b4f
Their shared secret, K:
  4a5d9d5ba4ce2de1728e3bf480350f25e07e21c947d19e3376f09b3c1e161742]]></artwork>
        </figure>
      </section>

      <section title="Curve448">
        <t>The <spanx style="verb">X448</spanx> function can be used in an ECDH protocol very much like the <spanx style="verb">X22519</spanx> function.</t>

        <t>If <spanx style="verb">X448</spanx> is to be used, the only differences are that Alice and Bob generate 56 random bytes (not 32) and calculate K_A = X448(f, 5) or K_B = X448(g, 5) where 5 is the u-coordinate of the base point and is encoded as a byte with value 5, followed by 55 zero bytes.</t>

        <t>As with <spanx style="verb">X25519</spanx>, both sides MUST check, without leaking extra information about the value of K, whether the resulting shared K is the all-zero value and abort if so.</t>

        <t>Test vector:</t>

        <figure align="center">
          <artwork align="left"><![CDATA[
Alice's private key, f:
  9a8f4925d1519f5775cf46b04b5800d4ee9ee8bae8bc5565d498c28d
  d9c9baf574a9419744897391006382a6f127ab1d9ac2d8c0a598726b
Alice's public key, X448(f, 5):
  9b08f7cc31b7e3e67d22d5aea121074a273bd2b83de09c63faa73d2c
  22c5d9bbc836647241d953d40c5b12da88120d53177f80e532c41fa0
Bob's private key, g:
  1c306a7ac2a0e2e0990b294470cba339e6453772b075811d8fad0d1d
  6927c120bb5ee8972b0d3e21374c9c921b09d1b0366f10b65173992d
Bob's public key, X448(g, 5):
  3eb7a829b0cd20f5bcfc0b599b6feccf6da4627107bdb0d4f345b430
  27d8b972fc3e34fb4232a13ca706dcb57aec3dae07bdc1c67bf33609
Their shared secret, K:
  fe2d52f1ca113e5441538037dc4a9d4cb381035fb4a990ac50ac4333
  63dc072301d1d4f2e82883b35103be96068c11e7c84b8fff74bb6ab0]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="generation" title="Deterministic Generation">
      <t>This section specifies the procedure that was used to generate the above curves; specifically it defines how to generate the parameter A of the Montgomery curve y^2 = x^3 + Ax^2 + x. This procedure is intended to be as objective as can reasonably be achieved so that it's clear that no untoward considerations influenced the choice of curve. The input to this process is p, the prime that defines the underlying field. The size of p determines the amount of work needed to compute a discrete logarithm in the elliptic curve group and choosing a precise p depends on many implementation concerns. The performance of the curve will be dominated by operations in GF(p) so carefully choosing a value that allows for easy reductions on the intended architecture is critical. This document does not attempt to articulate all these considerations.</t>

      <t>The value (A-2)/4 is used in several of the elliptic curve point arithmetic formulas. For simplicity and performance reasons, it is beneficial to make this constant small, i.e. to choose A so that (A-2) is a small integer which is divisible by four.</t>

      <t>For each curve at a specific security level:</t>
      <t>
        <list style="numbers">
          <t>The trace of Frobenius MUST NOT be in {0, 1} in order to rule out the attacks described in <xref target="smart" />, <xref target="satoh" />, and <xref target="semaev" />, as in <xref target="brainpool"/> and <xref target="safecurves"/>.</t>
          <t>MOV Degree: the embedding degree k MUST be greater than (r - 1) / 100, as in <xref target="brainpool"/> and <xref target="safecurves"/>.</t>
          <t>CM Discriminant: discriminant D MUST be greater than 2^100, as in <xref target="safecurves"/>.</t>
       </list>
      </t>

      <section title="p = 1 mod 4">
        <t>For primes congruent to 1 mod 4, the minimal cofactors of the curve and its twist are either {4, 8} or {8, 4}. We choose a curve with the latter cofactors so that any algorithms that take the cofactor into account don't have to worry about checking for points on the twist, because the twist cofactor will be the smaller of the two.</t>

        <t>To generate the Montgomery curve we find the minimal, positive A value, such that A &gt; 2 and (A-2) is divisible by four and where the cofactors are as desired. The <spanx style="verb">find1Mod4</spanx> function in the following Sage script returns this value given p:</t>
        <figure align="center" title="Generating a curve where p = 1 mod 4">
          <artwork align="left"><![CDATA[
def findCurve(prime, curveCofactor, twistCofactor):
    F = GF(prime)

    for A in xrange(3, 1e9):
        if (A-2) % 4 != 0:
          continue

        try:
          E = EllipticCurve(F, [0, A, 0, 1, 0])
        except:
          continue

        order = E.order()
        twistOrder = 2*(prime+1)-order

        if (order % curveCofactor == 0 and
            is_prime(order // curveCofactor) and
            twistOrder % twistCofactor == 0 and
            is_prime(twistOrder // twistCofactor)):
            return A

def find1Mod4(prime):
    assert((prime % 4) == 1)
    return findCurve(prime, 8, 4)
]]></artwork>
        </figure>
      </section>

      <section title="p = 3 mod 4">
        <t>For a prime congruent to 3 mod 4, both the curve and twist cofactors can be 4 and this is minimal. Thus we choose the curve with these cofactors and minimal, positive A such that A &gt; 2 and (A-2) is divisible by four. The <spanx style="verb">find3Mod4</spanx> function in the following Sage script returns this value given p:</t>

        <figure align="center" title="Generating a curve where p = 3 mod 4">
          <artwork align="left"><![CDATA[
def find3Mod4(prime):
    assert((prime % 4) == 3)
    return findCurve(prime, 4, 4)
]]></artwork>
        </figure>
      </section>

      <section title="Base points">
        <t>The base point for a curve is the point with minimal, positive u value that is in the correct subgroup. The <spanx style="verb">findBasepoint</spanx> function in the following Sage script returns this value given p and A:</t>

        <figure align="center" title="Generating the base point">
          <artwork align="left"><![CDATA[
def findBasepoint(prime, A):
    F = GF(prime)
    E = EllipticCurve(F, [0, A, 0, 1, 0])

    for uInt in range(1, 1e3):
      u = F(uInt)
      v2 = u^3 + A*u^2 + u
      if not v2.is_square():
        continue
      v = v2.sqrt()

      point = E(u, v)
      order = point.order()
      if order > 8 and order.is_prime():
        return point
]]></artwork>
        </figure>
      </section>
    </section>


    <section title="Acknowledgements">
      <t>This document merges <spanx style="verb">draft-black-rpgecc-01</spanx> and <spanx style="verb">draft-turner-thecurve25519function-01</spanx>. The following authors of those documents wrote much of the text and figures but are not listed as authors on this document: Benjamin Black, Joppe W. Bos, Craig Costello, Patrick Longa, Michael Naehrig and Watson Ladd.</t>

      <t>The authors would also like to thank Tanja Lange, Rene Struik and Rich Salz for their reviews and contributions.</t>

      <t>The curve25519 function was developed by Daniel J. Bernstein in <xref target="curve25519"/>.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;
    </references>

    <references title="Informative References">
      <!-- A reference written by by an organization not a person. -->

      <reference anchor="smart">
        <front>
          <title>The discrete logarithm problem on elliptic curves of trace one</title>
          <author fullname="Nigel Smart" initials="N.S." surname="Smart" />
          <date year="1999" />
        </front>
      </reference>

      <reference anchor="satoh">
        <front>
          <title>Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves</title>
          <author fullname="Takakazu Satoh" initials="T.S." surname="Satoh" />
          <author fullname="Kiyomichi Araki" initials="K.A." surname="Araki" />
          <date year="1998" />
        </front>
      </reference>

      <reference anchor="semaev">
        <front>
          <title>Evaluation of discrete logarithms on some elliptic curves</title>
          <author fullname="Igor Semaev" initials="I.S." surname="Semaev" />
          <date year="1998" />
        </front>
      </reference>

      <reference anchor="brainpool" target="http://www.ecc-brainpool.org/download/Domain-parameters.pdf">
        <front>
          <title>ECC Brainpool Standard Curves and Curve Generation</title>
          <author>
            <organization>ECC Brainpool</organization>
          </author>
          <date day ="19" month="October" year="2005" />
        </front>
      </reference>

      <reference anchor="safecurves"
                 target="http://safecurves.cr.yp.to/">
        <front>
          <title>SafeCurves: choosing safe curves for elliptic-curve cryptography</title>
          <author fullname="Daniel J. Bernstein" initials="D.J.B." surname="Bernstein" />
          <author fullname="Tanja Lange" initials="T.J." surname="Lange" />
          <date day="13" month="Oct" year="2013" />
        </front>
      </reference>

      <reference anchor="NIST"
                 target="http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf">
        <front>
          <title>Recommended Elliptic Curves for Federal Government Use</title>

          <author>
            <organization>National Institute of Standards</organization>
          </author>

          <date month="July" year="1999" />
        </front>
      </reference>

      <reference anchor="SEC1"
                 target="http://www.secg.org/collateral/sec1_final.pdf">
        <front>
          <title>SEC 1: Elliptic Curve Cryptography</title>

          <author>
            <organization>Certicom Research</organization>
          </author>

          <date day="20" month="September" year="2000" />
        </front>
      </reference>

      <reference anchor="curve25519" target="http://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf">
        <front>
          <title>Curve25519 -- new Diffie-Hellman speed records</title>
          <author fullname="Daniel J. Bernstein" initials="D.J." surname="Bernstein"/>
          <date year="2006"/>
        </front>
      </reference>

      <reference anchor="montgomery" target="http://www.ams.org/journals/mcom/1987-48-177/S0025-5718-1987-0866113-7/S0025-5718-1987-0866113-7.pdf">
        <front>
          <title>Speeding the Pollard and elliptic curve methods of factorization</title>
          <author fullname="Peter L. Montgomery" initials="P." surname="Montgomery"/>
          <date year="1983"/>
        </front>
      </reference>

      <reference anchor="ed25519" target="http://ed25519.cr.yp.to/ed25519-20110926.pdf">
        <front>
          <title>High-speed high-security signatures</title>
          <author fullname="Daniel J. Bernstein" initials="D.J." surname="Bernstein"/>
          <author fullname="Niels Duif" initials="N." surname="Duif"/>
          <author fullname="Tanja Lange" initials="T." surname="Lange"/>
          <author fullname="Peter Schwabe" initials="P." surname="Schwabe"/>
          <author fullname="Bo-Yin Yang" initials="B.Y." surname="Yang"/>
          <date year="2011"/>
        </front>
      </reference>

      <reference anchor="goldilocks" target="http://eprint.iacr.org/2015/625.pdf">
        <front>
          <title>Ed448-Goldilocks, a new elliptic curve</title>
          <author fullname="Mike Hamburg" initials="M." surname="Hamburg"/>
          <date year="2015"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
