CFRG A. Langley
Internet-Draft Google
Intended status: Informational M. Hamburg
Expires: February 27, 2016 Rambus Cryptography Research
S. Turner
IECA, Inc.
August 26, 2015

Elliptic Curves for Security


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 27, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Since the initial standardization of elliptic curve cryptography (ECC) in [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 [NIST].

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.

2. Requirements Language

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 RFC 2119 [RFC2119].

3. Notation

Throughout this document, the following notation is used:

Denotes the prime number defining the underlying field.
The finite field with p elements.
An element in the finite field GF(p), not equal to -2 or 2.
A non-zero element in the finite field GF(p), not equal to 1, in the case of an Edwards curve, or not equal to -1, in the case of a twisted Edwards curve.
A generator point defined over GF(p) of prime order.
The x-coordinate of the elliptic curve point P on a (twisted) Edwards curve.
The y-coordinate of the elliptic curve point P on a (twisted) Edwards curve.
u, v
Coordinates on a Montgomery curve.
x, y
Coordinates on a (twisted) Edwards curve.

4. Recommended Curves

4.1. Curve25519

For the ~128-bit security level, the prime 2^255-19 is recommended for performance on a wide-range of architectures. Few primes of the form 2^c-s with s small exist between 2^250 and 2^521, and other choices of coefficient are not as competitive in performance. This prime is congruent to 1 mod 4 and the derivation procedure in Section 7 results in the following Montgomery curve v^2 = u^3 + A*u^2 + u, called curve25519:

2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed

The base point is u = 9, v = 14781619447589544791020593568409986887264606134616475288964881837755586237401.

This curve is birationally equivalent to a twisted Edwards curve -x^2 + y^2 = 1 + d*x^2*y^2, called edwards25519, where:

2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed

The birational maps are:

  (u, v) = ((1+y)/(1-y), sqrt(-486664)*u/x)
  (x, y) = (sqrt(-486664)*u/v, (u-1)/(u+1)

The Montgomery curve defined here is equal to the one defined in [curve25519] and the equivalent twisted Edwards curve is equal to the one defined in [ed25519].

4.2. Curve448

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 Section 7 results in the following Montgomery curve, called curve448:

2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d

The base point is u = 5, v = 355293926785568175264127502063783334808976399387714271831880898435169088786967410002932673765864550910142774147268105838985595290606362.

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

2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d

The birational maps are:

  (u, v) = ((y-1)/(y+1), sqrt(156324)*u/x)
  (x, y) = (sqrt(156324)*u/v, (1+u)/(1-u)

Both of those curves are also 4-isogenous to the following Edwards curve x^2 + y^2 = 1 + d*x^2*y^2, called edwards448, where:

2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d

The 4-isogeny maps between the Montgomery curve and this Edwards curve are:

  (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))

The curve edwards448 defined here is also called "Goldilocks" and is equal to the one defined in [goldilocks].

5. The X25519 and X448 functions

The X25519 and X448 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.

The 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.

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.

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:

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)])

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}.

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)

To implement the X25519(k, u) and X448(k, u) functions (where k is the scalar and u is the u-coordinate) first decode k and u and then perform the following procedure, which is taken from [curve25519] and based on formulas from [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.

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))

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

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

The cswap function SHOULD be implemented in constant time (i.e. independent of the swap argument). For example, this can be done as follows:

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)

Where mask(swap) 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.

5.1. Side-channel considerations

X22519 and X448 are designed so that fast, constant-time implementations are easier to produce. The procedure above ensures that the same sequence of field operations is performed for all values of the secret key, thus eliminating a common source of side-channel leakage. However, this alone does not prevent all side-channels by itself. It is important that the pattern of memory accesses and jumps not depend on the values of any of the bits of k. It is also important that the arithmetic used not leak information about the integers modulo p, for example by having b*c be distinguishable from c*c. On some architectures, even primitive machine instructions, such as single-word division, can have variable timing based on their inputs.

Side-channel attacks are an active research area that still sees significant, new results. Implementors are advised to follow this research closely.

5.2. Test vectors

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:


Input scalar:
Input scalar as a number (base 10):
Input u-coordinate:
Input u-coordinate as a number:
Output u-coordinate:

Input scalar:
Input scalar as a number (base 10):
Input u-coordinate:
Input u-coordinate as a number:
Output u-coordinate:


Input scalar:
Input scalar as a number (base 10):
  5991891753738964027837560161452132561572308560850261299268914594686 \
Input u-coordinate:
Input u-coordinate as a number:
  3822399108141073301162299612348993770314163652405713251483465559224 \
Output u-coordinate:

Input scalar:
Input scalar as a number (base 10):
  6332543359069705927792594815348623723825251552520289610564040013321 \
Input u-coordinate:
Input u-coordinate as a number:
  6227617977583254444629220684312341806495903900248112997616251537672 \
Output u-coordinate:

The second type of test vector consists of the result of calling the function in question a specified number of times. Initially, set k and u to be the following values:

For X25519:
For X448:

For each iteration, set k to be the result of calling the function and u to be the old value of k. The final result is the value left in k.


After one iteration:
After 1,000 iterations:
After 1,000,000 iterations:


After one iteration:
After 1,000 iterations:
After 1,000,000 iterations:

6. Diffie-Hellman

6.1. Curve25519

The X25519 function can be used in an elliptic-curve Diffie-Hellman (ECDH) protocol as follows:

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.

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

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

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.

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.

Test vector:

Alice's private key, f:
Alice's public key, X25519(f, 9):
Bob's private key, g:
Bob's public key, X25519(g, 9):
Their shared secret, K:

6.2. Curve448

The X448 function can be used in an ECDH protocol very much like the X22519 function.

If X448 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.

As with X25519, 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.

Test vector:

Alice's private key, f:
Alice's public key, X448(f, 5):
Bob's private key, g:
Bob's public key, X448(g, 5):
Their shared secret, K:

7. Deterministic Generation

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.

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.

For each curve at a specific security level:

  1. The trace of Frobenius MUST NOT be in {0, 1} in order to rule out the attacks described in [smart], [satoh], and [semaev], as in [brainpool] and [safecurves].
  2. MOV Degree: the embedding degree k MUST be greater than (r - 1) / 100, as in [brainpool] and [safecurves].
  3. CM Discriminant: discriminant D MUST be greater than 2^100, as in [safecurves].

7.1. p = 1 mod 4

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.

To generate the Montgomery curve we find the minimal, positive A value, such that A > 2 and (A-2) is divisible by four and where the cofactors are as desired. The find1Mod4 function in the following Sage script returns this value given p:

def findCurve(prime, curveCofactor, twistCofactor):
    F = GF(prime)

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

          E = EllipticCurve(F, [0, A, 0, 1, 0])

        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)

Generating a curve where p = 1 mod 4

7.2. p = 3 mod 4

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 > 2 and (A-2) is divisible by four. The find3Mod4 function in the following Sage script returns this value given p:

def find3Mod4(prime):
    assert((prime % 4) == 3)
    return findCurve(prime, 4, 4)

Generating a curve where p = 3 mod 4

7.3. Base points

The base point for a curve is the point with minimal, positive u value that is in the correct subgroup. The findBasepoint function in the following Sage script returns this value given p and A:

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():
      v = v2.sqrt()

      point = E(u, v)
      order = point.order()
      if order > 8 and order.is_prime():
        return point

Generating the base point

8. Acknowledgements

This document merges draft-black-rpgecc-01 and draft-turner-thecurve25519function-01. 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.

The authors would also like to thank Tanja Lange, Rene Struik, Rich Salz, Ilari Liusvaara, Deirdre Connolly and Simon Josefsson for their reviews and contributions.

The curve25519 function was developed by Daniel J. Bernstein in [curve25519].

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

9.2. Informative References

[brainpool] ECC Brainpool, "ECC Brainpool Standard Curves and Curve Generation", October 2005.
[curve25519] Bernstein, D., "Curve25519 -- new Diffie-Hellman speed records", 2006.
[ed25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P. and B. Yang, "High-speed high-security signatures", 2011.
[goldilocks] Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", 2015.
[montgomery] Montgomery, P., "Speeding the Pollard and elliptic curve methods of factorization", 1983.
[NIST] National Institute of Standards, "Recommended Elliptic Curves for Federal Government Use", July 1999.
[safecurves] Bernstein, D. and T. Lange, "SafeCurves: choosing safe curves for elliptic-curve cryptography", Oct 2013.
[satoh] Satoh, T. and K. Araki, "Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves", 1998.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", September 2000.
[semaev] Semaev, I., "Evaluation of discrete logarithms on some elliptic curves", 1998.
[smart] Smart, N., "The discrete logarithm problem on elliptic curves of trace one", 1999.

Authors' Addresses

Adam Langley Google 345 Spear St San Francisco, CA 94105 US EMail:
Mike Hamburg Rambus Cryptography Research 425 Market Street, 11th Floor San Francisco, CA 94105 US EMail:
Sean Turner IECA, Inc. 3057 Nutley Street Suite 106 Fairfax, VA 22031 US EMail: