Some common implementation considerations include:
Domain parameters To use ECC, all parties must agree on all the elements defining the elliptic curve, that is, the
domain parameters of the scheme. The underlying finite field is typically either a prime field, denoted \mathbb{F}_p, or a binary field, denoted \mathbb{F}_{2^m}. In the binary case, m and an irreducible reduction polynomial f specify the field representation; f is not an auxiliary curve. The elliptic curve is defined by the coefficients in its defining equation. Finally, the cyclic subgroup is defined by its
generator (a.k.a.
base point)
G. For cryptographic application, the
order of
G, that is the smallest positive number
n such that n G = \mathcal{O} (the
point at infinity of the curve, and the
identity element), is normally prime. Since
n is the size of a subgroup of E(\mathbb{F}_q), it follows from
Lagrange's theorem that the number h = \frac{1}{n}|E(\mathbb{F}_q)| is an integer. In cryptographic applications, this number
h, called the
cofactor, is usually small; protocols using curves with cofactors greater than 1 must handle the cofactor appropriately. To summarize: in the prime case, the domain parameters are (p,a,b,G,n,h); in the binary case, they are (m,f,a,b,G,n,h). Unless there is an assurance that domain parameters were generated by a party trusted with respect to their use, the domain parameters
must be validated before use. The generation of domain parameters is not usually done by each participant because this involves computing
the number of points on a curve which is time-consuming and troublesome to implement. As a result, several standard bodies published domain parameters of elliptic curves for several common field sizes. Such domain parameters are commonly known as "standard curves" or "named curves"; a named curve can be referenced either by name or by the unique
object identifier defined in the standard documents: •
NIST, SP 800-186: Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters SECG test vectors are also available. NIST has approved many SECG curves, so there is a significant overlap between the specifications published by NIST and SECG. EC domain parameters may be specified either by value or by name. If, despite the preceding admonition, one decides to construct one's own domain parameters, one should select the underlying field and then use one of the following strategies to find a curve with appropriate (i.e., near prime) number of points using one of the following methods: • Select a random curve and use a general point-counting algorithm, for example,
Schoof's algorithm or the
Schoof–Elkies–Atkin algorithm, • Select a random curve from a family which allows easy calculation of the number of points (e.g.,
Koblitz curves), or • Select the number of points and generate a curve with this number of points using the
complex multiplication technique. Several classes of curves are weak and should be avoided: • Curves over \mathbb{F}_{2^m} with non-prime
m are vulnerable to
Weil descent attacks. • Curves such that
n divides p^B-1 (where
p is the characteristic of the field:
q for a prime field, or 2 for a binary field) for sufficiently small
B are vulnerable to Menezes–Okamoto–Vanstone (MOV) attack which applies usual
discrete logarithm problem (DLP) in a small-degree extension field of \mathbb{F}_p to solve ECDLP. The bound
B should be chosen so that
discrete logarithms in the field \mathbb{F}_{p^B} are at least as difficult to compute as discrete logs on the elliptic curve E(\mathbb{F}_q). • Curves such that |E(\mathbb{F}_q)| = q are vulnerable to the attack that maps the points on the curve to the additive group of \mathbb{F}_q.
Key sizes Because all the fastest known algorithms that allow one to solve the ECDLP (
baby-step giant-step,
Pollard's rho, etc.), need O(\sqrt{n}) steps, it follows that the size of the underlying field should be roughly twice the security parameter. For example, for 128-bit security one needs a curve over \mathbb{F}_q, where q \approx 2^{256}. This can be contrasted with finite-field cryptography (e.g.,
DSA) which requires 3072-bit public keys and 256-bit private keys, and integer factorization cryptography (e.g.,
RSA) which requires a 3072-bit value of
n, where the private key should be just as large. However, the public key may be smaller to accommodate efficient encryption, especially when processing power is limited. Historic public ECDLP challenge records include a 112-bit key for the prime field case and a 109-bit key for the binary field case. For the prime field case, this was broken in July 2009 using a cluster of over 200
PlayStation 3 game consoles and could have been finished in 3.5 months using this cluster when running continuously. The binary field case was broken in April 2004 using 2600 computers over 17 months. The binary-field ECC2K-130 challenge has also been targeted by distributed computation using CPUs, GPUs, and FPGAs.
Projective coordinates A close examination of the addition rules shows that in order to add two points, one needs not only several additions and multiplications in \mathbb{F}_q but also an
inversion operation. The
inversion (for given x \in \mathbb{F}_q find y \in \mathbb{F}_q such that x y = 1) is one to two orders of magnitude slower than multiplication. However, points on a curve can be represented in different coordinate systems which do not require an
inversion operation to add two points. Several such systems were proposed: in the
projective system each point is represented by three coordinates (X,Y,Z) using the following relation: x = \frac{X}{Z}, y = \frac{Y}{Z}; in the
Jacobian system a point is also represented with three coordinates (X,Y,Z), but a different relation is used: x = \frac{X}{Z^2}, y = \frac{Y}{Z^3}; in the
López–Dahab system the relation is x = \frac{X}{Z}, y = \frac{Y}{Z^2}; in the
modified Jacobian system the same relations are used but four coordinates are stored and used for calculations (X,Y,Z,aZ^4); and in the
Chudnovsky Jacobian system five coordinates are used (X,Y,Z,Z^2,Z^3). Note that there may be different naming conventions, for example,
IEEE P1363-2000 standard uses "projective coordinates" to refer to what is commonly called Jacobian coordinates. An additional speed-up is possible if mixed coordinates are used.
Fast reduction Reduction modulo
p (which is needed for addition and multiplication) can be executed much faster if the prime
p is a
pseudo-Mersenne prime (Solinas prime), that is p \approx 2^d; for example, p = 2^{521} - 1 (P-521) or p = 2^{256} - 2^{32} - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1. (P-256) Compared to
Barrett reduction, there can be an order of magnitude speed-up. The speed-up here is a practical rather than theoretical one, and derives from the fact that the moduli of numbers against numbers near powers of two can be performed efficiently by computers operating on binary numbers with
bitwise operations. The curves over \mathbb{F}_p with pseudo-Mersenne P-256 and P-384 are recommended by NIST in SP 800-186. The NIST curves also use
a = −3, which improves addition in Jacobian coordinates. Bernstein and
Lange have criticized some design choices of the NIST curves and list alternative criteria for curve selection in the SafeCurves project. Other widely deployed curves also use primes with special forms that allow efficient reduction, such as p = 2^{255} - 19 for Curve25519 and 2^{448} - 2^{224} - 1 for Curve448. == Security ==