]>
Elliptic Curves for SecurityGoogle345 Spear StSan FranciscoCA94105USagl@google.comAkamai Technologies8 Cambridge CenterCambridgeMA02142USrsalz@akamai.comIECA, Inc.3057 Nutley StreetSuite 106FairfaxVA22031USturners@ieca.com
General
CFRGelliptic curvecryptographyeccThis memo describes an algorithm for deterministically generating parameters for elliptic curves over prime fields offering high practical security in cryptographic applications, including Transport Layer Security (TLS) and X.509 certificates. It also specifies a specific curve at the ~128-bit security level and a specific curve at the ~224-bit security level.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, various '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 generating cryptographic elliptic curves over a given prime field. 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 input parameters that would permit 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 when 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 element in the finite field GF(p), not equal to -1 or zero.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.This section describes the generation of the curve parameter, namely A, of the Montgomery curve y^2 = x^3 + Ax^2 + x. 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. 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 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 is larger.To generate the Montgomery curve we find the minimal, positive A value such (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: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) is divisible by four. The find3Mod4 function in the following Sage script returns this value given p: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: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 above procedure results in the following Montgomery curve, called curve25519:2^255-194866622^252 + 0x14def9dea2f79cd65812631a5cf5d3ed8The base point is u = 9, v = 14781619447589544791020593568409986887264606134616475288964881837755586237401.This curve is isomorphic to the twisted Edwards curve -x^2 + y^2 = 1 - d*x^2*y^2 where:2^255-19370957059346694393431380835087545651895421138798432190163887855330859402835552^252 + 0x14def9dea2f79cd65812631a5cf5d3ed81511222134953540077250115140958853151145401269304185720604611328394984776220246316835694926478169428394003475163141307993866256225615783033603165251855960The isomorphism maps are: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 .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 above procedure results in the following Montgomery curve, called curve448:2^448-2^224-11563262^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d4The base point is u = 5, v =
3552939267855681752641275020637833348089763993877142718318808984351 \
69088786967410002932673765864550910142774147268105838985595290606362.This curve is isomorphic to the Edwards curve x^2 + y^2 = 1 + d*x^2*y^2 where:2^448-2^224-16119758507445291761604232209655533175432196968710166263289689364150 \
878600426364748917855992836660204147686789799893781470654628155450172^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d43453974930397295163740086041505374102666552600751832902164069702816 \
456950736723444304817877593406332217083915834240417889241245677007323634193621478034452746619039440022671768206803436590301407450995903 \
06164083365386343198191849338272965044442230921818680526749009182718The isomorphism maps are:That curve is also 4-isogenous to the following Edward's curve x^2 + y^2 = 1 + d*x^2*y^2, called Ed448-Goldilocks:2^448-2^224-1-390812^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d4The 4-isogeny maps between the Montgomery curve and the Edward's curve are:The curve25519 and curve448 functions performs 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 strings and this specification defines their encoding.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 curve25519 (but not curve448) 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.For example, 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 curve25519 and 448 for curve448:(EDITORS 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.)Scalars are assumed to be randomly generated bytes. For curve25519, in order to decode 32 bytes into 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 curve448, 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}.To implement the curve25519(k, u) and curve448(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, taken from and based on formulas from . All calculations are performed in GF(p), i.e., they are performed modulo p. The constant a24 is (486662 - 2) / 4 = 121665 for curve25519, and (156326 - 2) / 4 = 39081 for curve448.(TODO: Note the difference in the formula from Montgomery's original paper. See https://www.ietf.org/mail-archive/web/cfrg/current/msg05872.html.)Finally, encode the resulting value as 32 or 56 bytes in little-endian order.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 k. 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).The cswap instruction SHOULD be implemented in constant time (independent of swap) as follows:where swap is 1 or 0. Alternatively, an implementation MAY use the following: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) = 1 - swap. The latter version is often more efficient.The curve25519 function can be used in an ECDH protocol as follows:Alice generates 32 random bytes in f[0] to f[31] and transmits K_A = curve25519(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 = curve25519(g, 9) and transmits it to Alice.Alice computes curve25519(f, K_B); Bob computes curve25519(g, K_A) using their generated values and the received input.Both now share K = curve25519(f, curve25519(g, 9)) = curve25519(g, curve25519(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, such as hashing K, to compute a key.The check for the all-zero value results from the fact that the curve25519 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.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, Mike Hamburg, Patrick Longa, Michael Naehrig and Watson Ladd.The authors would also like to thank Tanja Lange and Rene Struik for their reviews.
&RFC2119;
The discrete logarithm problem on elliptic curves of trace oneFermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curvesEvaluation of discrete logarithms on some elliptic curvesECC Brainpool Standard Curves and Curve GenerationECC BrainpoolSafeCurves: choosing safe curves for elliptic-curve cryptographyRecommended Elliptic Curves for Federal Government UseNational Institute of StandardsSEC 1: Elliptic Curve CryptographyCerticom ResearchCurve25519 -- new Diffie-Hellman speed recordsSpeeding the Pollard and elliptic curve methods of factorizationHigh-speed high-security signatures