Elliptic Curves for Security

This document is a merging of draft-black-rpgecc-01 (by Benjamin Black, Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig) and draft-turner-thecurve25519function-01 (by Watson Ladd, Rich Salz and Sean Turner). They are the actual authors of the words and figures, but authorship also implies support and so are not listed as authors until they have confirmed that they support this document. None the less, they deserve any credit for the contents.

Since the initial standardization of elliptic curve cryptography (ECC) in 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, different 'special' prime shapes which 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 in . This memo describes a deterministic algorithm for generation of elliptic curves for cryptography. The constraints in the generation process produce curves that support constant-time, exception-free scalar multiplications that are resistant to a wide range of side-channel attacks including timing and cache attacks, thereby offering high practical security in cryptographic applications. The deterministic algorithm operates without any hidden parameters, reliance on randomness or any other processes offering opportunities for manipulation of the resulting curves. The selection between curve models is determined by choosing the curve form that supports the fastest (currently known) complete formulas for each modularity option of the underlying field prime. Specifically, the Edwards curve x^2 + y^2 = 1 + dx^2y^2 is used with primes p with p = 3 mod 4, and the twisted Edwards curve -x^2 + y^2 = 1 + dx^2y^2 is used for primes p with p = 1 mod 4.

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.

For each curve at a specific security level: The domain parameters SHALL be generated in a simple, deterministic manner, without any secret or random inputs. The derivation of the curve parameters is defined in . The trace of Frobenius MUST NOT be in {0, 1} in order to rule out the attacks described in , , and , as in . MOV Degree: the embedding degree k MUST be greater than (r - 1) / 100, as in . CM Discriminant: discriminant D MUST be greater than 2^100, as in .

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 -1 or zero. An Edwards curve: an elliptic curve over GF(p) with equation x^2 + y^2 = 1 + dx^2y^2. A twisted Edwards curve where a=-1: an elliptic curve over GF(p) with equation -x^2 + y^2 = 1 + dx^2y^2. The largest odd divisor of the number of GF(p)-rational points on a (twisted) Edwards curve. The largest odd divisor of the number of GF(p)-rational points on the non-trivial quadratic twist of a (twisted) Edwards curve. The cofactor of the subgroup of order oddDivisor in the group of GF(p)-rational points of a (twisted) Edwards curve. The cofactor of the subgroup of order oddDivisor in the group of GF(p)-rational points on the non-trivial quadratic twist of a (twisted) Edwards curve. The trace of Frobenius of Ed or tEd such that #Ed(GF(p)) = p + 1 - trace or #tEd(GF(p)) = p + 1 - trace, respectively. A generator point defined over GF(p) of prime order oddDivisor on Ed or tEd. The x-coordinate of the elliptic curve point P. The y-coordinate of the elliptic curve point P.

This section describes the generation of the curve parameter, namely d, of the elliptic 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) and thus carefully choosing a value that allows for easy reductions on the intended architecture is critical for performance. This document does not attempt to articulate all these considerations.

For p = 3 mod 4, the elliptic curve Ed in Edwards form is determined by the non-square element d from GF(p) (not equal to -1 or zero) with smallest absolute value such that #Ed(GF(p)) = cofactor * oddDivisor, #Ed'(GF(p)) = cofactor' * oddDivisor', cofactor = cofactor' = 4, and both subgroup orders oddDivisor and oddDivisor' are prime. In addition, care must be taken to ensure the MOV degree and CM discriminant requirements from are met. These cofactors are chosen because they are minimal.

0) then d = -d else d = -d + 1 end if until d is not a square in GF(p) Compute oddDivisor, oddDivisor', cofactor and cofactor' where #Ed(GF(p)) = cofactor * oddDivisor, #Ed'(GF(p)) = cofactor' * oddDivisor', cofactor and cofactor' are powers of 2 and oddDivisor, oddDivisor' are odd. until ((cofactor = cofactor' = 4), oddDivisor is prime and oddDivisor' is prime) 3. Output d ]]>

For a prime p = 1 mod 4, the elliptic curve tEd in twisted Edwards form is determined by the non-square element d from GF(p) (not equal to -1 or zero) with smallest absolute value such that #tEd(GF(p)) = cofactor * oddDivisor, #tEd'(GF(p)) = cofactor' * oddDivisor', cofactor = 8, cofactor' = 4 and both subgroup orders oddDivisor and oddDivisor' are prime. In addition, care must be taken to ensure the MOV degree and CM discriminant requirements from are met. These cofactors are chosen so that they are minimal such that the cofactor of the main curve is greater than the cofactor of the twist. It's not possible in this case for the cofactors to be equal, but it is possible for the twist cofactor to be larger. The latter is considered dangerous because algorithms that depend on the cofactor of the curve may be vulnerable if a point on the twist is accepted.

0) then d = -d else d = -d + 1 end if until d is not a square in GF(p) Compute oddDivisor, oddDivisor', cofactor, cofactor' where #tEd(GF(p)) = cofactor * oddDivisor, #tEd'(GF(p)) = cofactor' * oddDivisor', cofactor and cofactor' are powers of 2 and oddDivisor, oddDivisor' are odd. until (cofactor = 8 and cofactor' = 4 and rd is prime and rd' is prime) 3. Output d ]]>

Any point with the correct order will serve as a generator for the group. The following algorithm computes a possible generator by taking the smallest positive value x in GF(p) (when represented as an integer) such that (x, y) is on the curve and such that (X(P),Y(P)) = 8 * (x, y) has large prime order oddDivisor.

For the ~128-bit security level, the prime 2^255-19 is recommended for performance over a wide-range of architectures. This prime is congruent to 1 mod 4 and the above procedure results in the following twisted Edwards curve, called intermediate25519: 2^255-19 121665 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed 8 In order to be compatible with widespread existing practice, the recommended curve is an isogeny of this curve. An isogeny is a "renaming" of the points on the curve and thus cannot affect the security of the curve: 2^255-19 37095705934669439343138083508754565189542113879843219016388785533085940283555 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed 8 15112221349535400772501151409588531511454012693041857206046113283949847762202 46316835694926478169428394003475163141307993866256225615783033603165251855960 The d value in the this curve is much larger than the generated curve and this might slow down some implementations. If this is a problem then implementations are free to calculate on the original curve, with small d as the isogeny map can be merged into the affine transform without any performance impact. The latter curve is isomorphic to a Montgomery curve defined by v^2 = u^3 + 486662u^2 + u where the maps are:

The base point maps onto the Montgomery curve such that u = 9, v = 14781619447589544791020593568409986887264606134616475288964881837755586237401. The Montgomery curve defined here is equal to the one defined in and the isomorphic twisted Edwards curve is equal to the one defined in .

When transmitting field elements in the Diffie-Hellman protocol below, they MUST be encoded as an array of bytes, x, in little-endian order such that x[0] + 256 * x[1] + 256^2 * x[2] + ... + 256^n * x[n] is congruent to the value modulo p and x[n] is minimal. On receiving such an array, implementations MUST mask the (8-log2(p)%8)%8 most-significant bits 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. (NOTE: draft-turner-thecurve25519function also says "Implementations MUST reject numbers in the range [2^255-19, 2^255-1], inclusive." but I'm not aware of any implementations that do so.)

This section describes how to perform Diffie-Hellman using curves generated by the above procedure. For safety reasons, Diffie-Hellman is performed on the Montgomery isomorphism of the curve and the public values transmitted are u coordinates. Let U denote the projection map from a point (u,v) on E, to u, extended so that U of the point at infinity is zero. U is surjective onto GF(p) if the v coordinate takes on values in GF(p) and in a quadratic extension of GF(p). Then DH(s, U(Q)) = U(sQ) is a function defined for all integers s and elements U(Q) of GF(p). Proper implementations use a restricted set of integers for s and only u-coordinates of points Q defined over GF(p). The remainder of this section describes how to compute this function quickly and securely, and use it in a Diffie- Hellman scheme. Let s be a 255 bits long integer, where s = sum s_i * 2^i with s_i in {0, 1}. Computing DH(s, u) is done by the following procedure, taken from based on formulas from . All calculations are performed in GF(p), i.e., they are performed modulo p. The parameter a24 is a24 = (486662 - 2) / 4 = 121665.

In 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 s. It is also important that the arithmetic used not leak information about the integers modulo p (such as having b * c distinguishable from c * c). The cswap instruction SHOULD be implemented in constant time (independent of s_t) as follows:

where s_t is 1 or 0. Alternatively, an implementation MAY use the following:

where mask(s_t) is the all-1 or all-0 word of the same length as x_2 and x_3, computed, e.g., as mask(s_t) = 1 - s_t. The latter version is often more efficient.

The DH function can be used in an ECDH protocol with the recommended curve as follows: Alice generates 32 random bytes in f[0] to f[31]. She masks the three rightmost bits of f[0] and the leftmost bit of f[31] to zero and sets the second leftmost bit of f[31] to 1. This means that f is of the form 2^254 + 8 * {0, 1, ..., 2^(251) - 1} as a little-endian integer. Alice then transmits K_A = DH(f, 9) to Bob, where 9 is the number 9. Bob similarly generates 32 random bytes in g[0] to g[31], applies the same masks, computes K_B = DH(g, 9) and transmits it to Alice. Alice computes DH(f, DH(g, 9)); Bob computes DH(g, DH(f, 9)) using their generated values and the received input. Both of them now share K = DH(f, DH(g, 9)) = DH(g, DH(f, 9)) as a shared secret. Alice and Bob can then use a key-derivation function, such as hashing K, to compute a key.

The following test vectors are taken from . All numbers are shown as little-endian hexadecimal byte strings: