Editing Elliptic-curve cryptography (section)

== Implementation ==
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 size of the field used is typically either prime (and denoted as p) or is a power of two (<math>2^m</math>); the latter case is called ''the binary case'', and this case necessitates the choice of an auxiliary curve denoted by ''f''.  Thus the field is defined by ''p'' in the prime case and the pair of ''m'' and ''f''<!--m and f are no longer defined before this in this article, except by me, and I don't know what I'm talking about--> in the binary case. The elliptic curve is defined by the constants ''a'' and ''b'' used in its defining equation. Finally, the cyclic subgroup is defined by its [[Generating set of a group|generator]] (a.k.a. ''base point'') ''G''. For cryptographic application, the [[order (group theory)|order]] of ''G'', that is the smallest positive number ''n'' such that <math>n G = \mathcal{O}</math> (the [[point at infinity]] of the curve, and the [[identity element]]), is normally prime. Since ''n'' is the size of a subgroup of <math>E(\mathbb{F}_p)</math> it follows from [[Lagrange's theorem (group theory)|Lagrange's theorem]] that the number <math>h = \frac{1}{n}|E(\mathbb{F}_p)|</math> is an integer. In cryptographic applications, this number ''h'', called the ''cofactor'', must be small (<math>h \le 4</math>) and, preferably, <math>h = 1</math>. To summarize: in the prime case, the domain parameters are <math>(p,a,b,G,n,h)</math>; in the binary case, they are <math>(m,f,a,b,G,n,h)</math>.

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.<!--TBD: validation procedure-->

The generation of domain parameters is not usually done by each participant because this involves computing [[counting points on elliptic curves|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]], [https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf Recommended Elliptic Curves for Government Use]
* [[SECG]], [http://www.secg.org/sec2-v2.pdf SEC 2: Recommended Elliptic Curve Domain Parameters]
* ECC Brainpool ({{IETF RFC|5639}}), [http://www.ecc-brainpool.org/download/Domain-parameters.pdf ECC Brainpool Standard Curves and Curve Generation]<ref>{{Webarchive|url=https://web.archive.org/web/20180417212206/http://www.ecc-brainpool.org/download/Domain-parameters.pdf |date=2018-04-17 }}</ref><ref>{{cite press release|url=https://www.secunet.com/en/about-us/news-events/article/elliptic-curve-cryptography-made-in-germany-1#:~:text=In%20contrast%2C%20the%20Brainpool%20curves,and%20from%20Euler's%20number%20e.|title=Elliptic Curve Cryptography "Made in Germany"|date=2014-06-25}}</ref>
SECG test vectors are also available.<ref>{{cite web |url=http://www.secg.org/download/aid-390/gec2.pdf |title=GEC 2: Test Vectors for SEC 1 |website=www.secg.org |format=PDF download |archive-url=https://web.archive.org/web/20130606004254/http://www.secg.org/download/aid-390/gec2.pdf |archive-date=2013-06-06}}</ref> 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 curve]]s), or
* Select the number of points and generate a curve with this number of points using the ''complex multiplication'' technique.<ref>{{Cite book |series=Lecture Notes in Computer Science |volume=877 |pages=250–263 |doi=10.1007/3-540-58691-1_64 |isbn=978-3-540-58691-3 |chapter=Constructing elliptic curves with given group order over large finite fields |title=Algorithmic Number Theory |year=1994 |last1=Lay |first1=Georg-Johann |last2=Zimmer |first2=Horst G. }}</ref>

Several classes of curves are weak and should be avoided:
* Curves over <math>\mathbb{F}_{2^m}</math> with non-prime ''m'' are vulnerable to [[Weil descent]] attacks.<ref>{{cite book |first1=S. D. |last1=Galbraith |first2=N. P. |last2=Smart |s2cid=15134380 |title=A cryptographic application of the Weil descent |year=1999 |series=Lecture Notes in Computer Science |volume=1746 |pages=799 |doi=10.1007/3-540-46665-7_23 |chapter=A Cryptographic Application of Weil Descent |isbn=978-3-540-66887-9 }}</ref><ref>{{cite web |first1=P. |last1=Gaudry |first2=F. |last2=Hess |first3=N. P. |last3=Smart |url=http://www.hpl.hp.com/techreports/2000/HPL-2000-10.pdf |title=Constructive and destructive facets of Weil descent on elliptic curves |work=Hewlett Packard Laboratories Technical Report |year=2000 |access-date=2006-01-02 |archive-date=2006-12-06 |archive-url=https://web.archive.org/web/20061206133559/http://hpl.hp.com/techreports/2000/HPL-2000-10.pdf |url-status=dead }}</ref>
* Curves such that ''n'' divides <math>p^B-1</math> (where ''p'' is the characteristic of the field: ''q'' for a prime field, or <math>2</math> for a binary field) for sufficiently small ''B'' are vulnerable to Menezes–Okamoto–Vanstone (MOV) attack<ref>{{cite journal |first1=A. |last1=Menezes |first2=T. |last2=Okamoto |first3=S. A. |last3=Vanstone |title=Reducing elliptic curve logarithms to logarithms in a finite field |journal=IEEE Transactions on Information Theory |volume=39 |issue=5 |year=1993 | doi =  10.1109/18.259647 |pages=1639–1646}}</ref><ref>{{cite journal |first=L. |last=Hitt |url=http://eprint.iacr.org/2006/415 |title=On an Improved Definition of Embedding Degree |journal=IACR ePrint Report |year=2006 |volume=415 }}</ref> which applies usual [[discrete logarithm problem]] (DLP) in a small-degree extension field of <math>\mathbb{F}_p</math> to solve ECDLP.  The bound ''B'' should be chosen so that [[discrete logarithm]]s in the field <math>\mathbb{F}_{p^B}</math> are at least as difficult to compute as discrete logs on the elliptic curve <math>E(\mathbb{F}_q)</math>.<ref>IEEE [http://grouper.ieee.org/groups/1363/P1363/index.html P1363] {{Webarchive|url=https://web.archive.org/web/20070213061138/http://grouper.ieee.org/groups/1363/P1363/index.html |date=2007-02-13 }}, section A.12.1</ref>
* Curves such that <math>|E(\mathbb{F}_q)| = q</math> are vulnerable to the attack that maps the points on the curve to the additive group of <math>\mathbb{F}_q</math>.<ref>{{cite journal |first=I. |last=Semaev |title=Evaluation of discrete logarithm in a group of ''p''-torsion points of an elliptic curve in characteristic ''p'' |journal=Mathematics of Computation |volume=67 |issue=221 |year=1998 |pages=353–356 |doi=10.1090/S0025-5718-98-00887-4 |bibcode=1998MaCom..67..353S |doi-access=free }}</ref><ref>{{cite journal |first=N. |last=Smart |title=The discrete logarithm problem on elliptic curves of trace one |journal=Journal of Cryptology |volume=12 |year=1999 |issue=3 |pages=193–196 |doi=10.1007/s001459900052 |url=http://www.hpl.hp.com/techreports/97/HPL-97-128.ps |citeseerx=10.1.1.17.1880 |s2cid=24368962 }}</ref><ref>{{cite journal |first1=T. |last1=Satoh |first2=K. |last2=Araki |title=Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves |journal=Commentarii Mathematici Universitatis Sancti Pauli |volume=47 |year=1998 }}</ref>

=== Key sizes ===
{{See also|Discrete logarithm records#Elliptic curves}}

Because all the fastest known algorithms that allow one to solve the ECDLP ([[baby-step giant-step]], [[Pollard's rho algorithm for logarithms|Pollard's rho]], etc.), need <math>O(\sqrt{n})</math> 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 <math>\mathbb{F}_q</math>, where <math>q \approx 2^{256}</math>. This can be contrasted with finite-field cryptography (e.g., [[Digital Signature Algorithm|DSA]]) which requires<ref>NIST, [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf Recommendation for Key Management—Part 1: general],  Special Publication 800-57, August 2005.</ref> 3072-bit public keys and 256-bit private keys, and integer factorization cryptography (e.g., [[RSA (algorithm)|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.

The hardest ECC scheme (publicly) broken to date{{When|date=November 2022}} had 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.<ref>{{cite web|url=http://lacal.epfl.ch/page81774.html|title=112-bit prime ECDLP solved – LACAL|website=lacal.epfl.ch|access-date=2009-07-11|archive-url=https://web.archive.org/web/20090715060838/http://lacal.epfl.ch/page81774.html|archive-date=2009-07-15|url-status=dead}}</ref> The binary field case was broken in April 2004 using 2600 computers over 17 months.<ref>{{cite web|url=http://www.certicom.com/index.php/2004-press-releases/36-2004-press-releases/300-solution-required-team-of-mathematicians-2600-computers-and-17-months- |title=Certicom Announces Elliptic Curve Cryptography Challenge Winner |work=Certicom |date=April 27, 2004 |url-status=dead |archive-url=https://web.archive.org/web/20110719233751/https://www.certicom.com/index.php/2004-press-releases/36-2004-press-releases/300-solution-required-team-of-mathematicians-2600-computers-and-17-months- |archive-date=2011-07-19 }}</ref>

A current project is aiming at breaking the ECC2K-130 challenge by Certicom, by using a wide range of different hardware: CPUs, GPUs, FPGA.<ref>{{cite web|url=http://www.ecc-challenge.info/|title=Breaking ECC2K-130|website=www.ecc-challenge.info}}</ref>

=== 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 <math>\mathbb{F}_q</math> but also an [[Modular multiplicative inverse|inversion]] operation. The [[Modular multiplicative inverse|inversion]] (for given <math>x \in \mathbb{F}_q</math> find <math>y \in \mathbb{F}_q</math> such that <math>x y = 1</math>) is one to two orders of magnitude slower<ref>{{cite journal|first1=Y. |last1=Hitchcock |first2=E. |last2=Dawson |first3=A. |last3=Clark |first4=P. |last4=Montague |url=http://anziamj.austms.org.au/V44/CTAC2001/Hitc/Hitc.pdf |title=Implementing an efficient elliptic curve cryptosystem over GF(p) on a smart card |year=2002 |journal=ANZIAM Journal |volume=44 |url-status=dead |archive-url=https://web.archive.org/web/20060327202009/http://anziamj.austms.org.au/V44/CTAC2001/Hitc/Hitc.pdf |archive-date=2006-03-27 }}</ref> than multiplication. However, points on a curve can be represented in different coordinate systems which do not require an [[Modular multiplicative inverse|inversion]] operation to add two points. Several such systems were proposed: in the ''projective'' system each point is represented by three coordinates <math>(X,Y,Z)</math> using the following relation: <math>x = \frac{X}{Z}</math>, <math>y = \frac{Y}{Z}</math>; in the ''Jacobian system'' a point is also represented with three coordinates <math>(X,Y,Z)</math>, but a different relation is used: <math>x = \frac{X}{Z^2}</math>, <math>y = \frac{Y}{Z^3}</math>; in the ''López–Dahab system'' the relation is <math>x = \frac{X}{Z}</math>, <math>y = \frac{Y}{Z^2}</math>; in the ''modified Jacobian'' system the same relations are used but four coordinates are stored and used for calculations <math>(X,Y,Z,aZ^4)</math>; and in the ''Chudnovsky Jacobian'' system five coordinates are used <math>(X,Y,Z,Z^2,Z^3)</math>. 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.<!--TBD: insert formulas--> An additional speed-up is possible if mixed coordinates are used.<ref>{{Cite book |first1=H. |last1=Cohen |author1-link=Henri Cohen (number theorist)|first2=A. |last2=Miyaji |author2-link=Atsuko Miyaji|first3=T. |last3=Ono |title=Advances in Cryptology — ASIACRYPT'98 |chapter=Efficient Elliptic Curve Exponentiation Using Mixed Coordinates |year=1998 |series=Lecture Notes in Computer Science |volume=1514 |pages=51–65 |doi=10.1007/3-540-49649-1_6 |isbn=978-3-540-65109-3 }}</ref>

=== Fast reduction (NIST curves) ===
Reduction modulo ''p'' (which is needed for addition and multiplication) can be executed much faster if the prime ''p'' is a [[pseudo-Mersenne prime]], that is <math>p \approx 2^d</math>; for example, <math>p = 2^{521} - 1</math> or <math>p = 2^{256} - 2^{32} - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1.</math> Compared to [[Barrett reduction]], there can be an order of magnitude speed-up.<ref>{{Cite book |first1=M. |last1=Brown |first2=D. |last2=Hankerson |first3=J. |last3=Lopez |first4=A. |last4=Menezes  |title=Topics in Cryptology — CT-RSA 2001 |chapter=Software Implementation of the NIST Elliptic Curves over Prime Fields |series=Lecture Notes in Computer Science |year=2001 |volume=2020 |pages=250–265 |doi=10.1007/3-540-45353-9_19 |isbn=978-3-540-41898-6 |url=http://cr.yp.to/bib/2000/brown-prime.ps |citeseerx=10.1.1.25.8619 }}</ref> 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 operation]]s.

The curves over <math>\mathbb{F}_p</math> with pseudo-Mersenne ''p'' are recommended by NIST. Yet another advantage of the NIST curves is that they use ''a''&nbsp;=&nbsp;−3, which improves addition in Jacobian coordinates.

According to Bernstein and Lange, many of the efficiency-related decisions in NIST FIPS 186-2 are suboptimal. Other curves are more secure and run just as fast.<ref>{{ cite web | author = Daniel J. Bernstein | author2 = Tanja Lange|author2-link=Tanja Lange | name-list-style = amp | title = SafeCurves: choosing safe curves for elliptic-curve cryptography | url = https://safecurves.cr.yp.to/ | access-date = 1 December 2013 }}</ref>