Elliptic-curve cryptography: Difference between revisions
imported>Johannfh m Add a link to NIST |
imported>Xo4v →Domain parameters: {{anchor|ECC Brainpool}} |
||
| Line 1: | Line 1: | ||
{{Short description|Approach to public-key cryptography}} | {{Short description|Approach to public-key cryptography}} | ||
'''Elliptic-curve cryptography''' ('''ECC''') is an approach to [[public-key cryptography]] based on the [[algebraic structure]] of [[elliptic curve]]s over [[finite field]]s. ECC allows smaller keys to provide equivalent security, compared to cryptosystems based on modular exponentiation in [[Finite field| | '''Elliptic-curve cryptography''' ('''ECC''') is an approach to [[public-key cryptography]] based on the [[algebraic structure]] of [[elliptic curve]]s over [[finite field]]s. ECC allows smaller keys to provide equivalent security, compared to cryptosystems based on modular exponentiation in [[Finite field|finite fields]], such as the [[RSA cryptosystem]] and [[ElGamal encryption | ElGamal cryptosystem]].<ref name=":0"/> | ||
Elliptic curves are applicable for [[key agreement]], [[digital signature]]s, [[Cryptographically secure pseudorandom number generator|pseudo-random generators]] and other tasks. Indirectly, they can be used for [[encryption]] by combining the key agreement with a [[Symmetric-key algorithm|symmetric encryption]] scheme. They are also used in several [[integer factorization]] [[algorithm]]s that have applications in cryptography, such as [[Lenstra elliptic-curve factorization]]. | Elliptic curves are applicable for [[key agreement]], [[digital signature]]s, [[Cryptographically secure pseudorandom number generator|pseudo-random generators]] and other tasks. Indirectly, they can be used for [[encryption]] by combining the key agreement with a [[Symmetric-key algorithm|symmetric encryption]] scheme. They are also used in several [[integer factorization]] [[algorithm]]s that have applications in cryptography, such as [[Lenstra elliptic-curve factorization]]. | ||
== History == | == History == | ||
{{expand section|a global view that expands coverage to include non-U.S. standards and standards bodies|date=March 2026}} | |||
The use of elliptic curves in cryptography was suggested independently by [[Neal Koblitz]]<ref>{{cite journal |first=N. |last=Koblitz |title=Elliptic curve cryptosystems |journal=Mathematics of Computation |volume=48 |issue=177 |year=1987 |pages=203–209 |doi= 10.2307/2007884|jstor=2007884 |doi-access=free }}</ref> and [[Victor S. Miller]]<ref>{{Cite book |first=V. |last=Miller |title=Advances in Cryptology — CRYPTO '85 Proceedings |chapter=Use of Elliptic Curves in Cryptography |volume=85 |pages=417–426 |doi=10.1007/3-540-39799-X_31 |series=Lecture Notes in Computer Science |date=1986 |isbn=978-3-540-16463-0 |s2cid=206617984 }}</ref> in 1985. Elliptic curve cryptography algorithms entered wide use in 2004 | The use of elliptic curves in cryptography was suggested independently by [[Neal Koblitz]]<ref>{{cite journal |first=N. |last=Koblitz |title=Elliptic curve cryptosystems |journal=Mathematics of Computation |volume=48 |issue=177 |year=1987 |pages=203–209 |doi= 10.2307/2007884|jstor=2007884 |doi-access=free }}</ref> and [[Victor S. Miller]]<ref>{{Cite book |first=V. |last=Miller |title=Advances in Cryptology — CRYPTO '85 Proceedings |chapter=Use of Elliptic Curves in Cryptography |volume=85 |pages=417–426 |doi=10.1007/3-540-39799-X_31 |series=Lecture Notes in Computer Science |date=1986 |isbn=978-3-540-16463-0 |s2cid=206617984 }}</ref> in 1985. Elliptic curve cryptography algorithms entered wide use starting in 2004. | ||
In 1999, [[National Institute of Standards and Technology|NIST]] recommended fifteen elliptic curves. | In 1999, U.S. [[National Institute of Standards and Technology|NIST]] recommended fifteen elliptic curves for use in the Digital Signature Standard. These curves were later specified in FIPS 186-4, which was superseded by FIPS 186-5 in 2023 and withdrawn in 2024.<ref name="nist-fips1864">{{cite web |title=FIPS 186-4, Digital Signature Standard (DSS) |publisher=[[National Institute of Standards and Technology]] |url=https://csrc.nist.gov/pubs/fips/186-4/final |access-date=30 April 2026}}</ref> NIST moved its recommended elliptic-curve domain parameters to Special Publication 800-186. SP 800-186 includes previously recommended Weierstrass curves and two Edwards curves for EdDSA; it also deprecates binary-field curves and strongly recommends use of prime curves.<ref name="nist-fips1865-sp800186">{{cite web |title=NIST Releases FIPS 186-5 and SP 800-186 |publisher=[[National Institute of Standards and Technology]] |date=3 February 2023 |url=https://csrc.nist.gov/news/2023/nist-releases-fips-186-5-and-sp-800-186 |access-date=30 April 2026}}</ref><ref name="nist-sp800186">{{cite report |last1=Chen |first1=Lily |last2=Moody |first2=Dustin |last3=Regenscheid |first3=Andrew |last4=Randall |first4=Karen |title=Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters |publisher=[[National Institute of Standards and Technology]] |date=February 2023 |id=NIST SP 800-186 |doi=10.6028/NIST.SP.800-186 |url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf |doi-access=free}}</ref> | ||
The | At the [[RSA Conference]] 2005, the [[National Security Agency]] (NSA) announced [[NSA Suite B|Suite B]], which used ECC for digital signature generation and key exchange.<ref name=":0">{{cite web|url=http://www.nsa.gov/business/programs/elliptic_curve.shtml |title=The Case for Elliptic Curve Cryptography |work=NSA |url-status=dead |archive-url=https://web.archive.org/web/20090117023500/http://www.nsa.gov/business/programs/elliptic_curve.shtml |archive-date=2009-01-17 }}</ref> Suite B was later superseded by the Commercial National Security Algorithm Suite (CNSA), and NSA announced CNSA 2.0 as a quantum-resistant transition suite for national security systems.<ref name="nsa-cnsa2">{{cite web |title=NSA Releases Future Quantum-Resistant Algorithm Requirements for National Security Systems |publisher=[[National Security Agency]] |date=7 September 2022 |url=https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/ |access-date=30 April 2026}}</ref> | ||
Since the early 2000s, cryptographic primitives based on bilinear mappings on various elliptic curve groups, such as the [[Weil pairing|Weil]] and [[Tate pairing]]s, have been studied. Schemes based on these primitives include [[identity-based encryption]] as well as pairing-based signatures, [[signcryption]], [[key agreement]], and [[proxy re-encryption]].<ref>{{cite journal |last1=Boneh |first1=Dan |last2=Franklin |first2=Matthew |title=Identity-based encryption from the Weil pairing |journal=SIAM Journal on Computing |volume=32 |issue=3 |year=2003 |pages=586–615 |doi=10.1137/S0097539701398521}}</ref> | |||
Elliptic curve cryptography is used successfully in numerous popular protocols, such as [[Transport Layer Security]] and [[Bitcoin]]. | Elliptic curve cryptography is used successfully in numerous popular protocols, such as [[Transport Layer Security]] and [[Bitcoin]]. | ||
| Line 27: | Line 24: | ||
{{further|#Quantum computing attack}} | {{further|#Quantum computing attack}} | ||
Additionally, in August 2015, the NSA announced that it | Additionally, in August 2015, the NSA announced that it planned to replace Suite B with a new cipher suite due to concerns about [[quantum computing]] attacks on ECC.<ref name="nsaquantum" /><ref name=nsaQCfaq>[https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf Commercial National Security Algorithm Suite and Quantum Computing FAQ] U.S. National Security Agency, January 2016.</ref> NSA later published CNSA 2.0 guidance for a transition to quantum-resistant algorithms for national security systems.<ref name="nsa-cnsa2" /> | ||
=== Patents === | === Patents === | ||
| Line 35: | Line 32: | ||
== Elliptic curve theory == | == Elliptic curve theory == | ||
For the purposes of this article, an ''elliptic curve'' is a [[plane curve]] over a [[finite field]] (rather than the real numbers) | For the purposes of this article, an ''elliptic curve'' is a [[plane curve]] over a [[finite field]] (rather than the real numbers). A common form for curves over finite fields of [[Characteristic (algebra)#Case of fields|characteristic]] not equal to 2 or 3 consists of the points satisfying the equation | ||
: <math>y^2 = x^3 + ax + b,</math> | : <math>y^2 = x^3 + ax + b,</math> | ||
along with a distinguished [[point at infinity]], denoted ∞. | along with a distinguished [[point at infinity]], denoted ∞. Curves over fields of characteristic 2 or 3, and curves used in other representations such as Montgomery or Edwards form, are written differently. | ||
This set of points, together with the [[Elliptic curve# | This set of points, together with the [[Elliptic curve#Group law|group operation of elliptic curves]], is an [[abelian group]], with the point at infinity as an identity element. The structure of the group is inherited from the [[Divisor (algebraic geometry)|divisor group]] of the underlying [[algebraic variety]]: | ||
: <math>\operatorname{Div}^0(E) \to \operatorname{Pic}^0(E) \simeq E.</math> | : <math>\operatorname{Div}^0(E) \to \operatorname{Pic}^0(E) \simeq E.</math> | ||
=== Application to cryptography === | === Application to cryptography === | ||
[[Public-key cryptography]] is based on the [[Intractability (complexity)#Intractability|intractability]] of certain mathematical [[Computational hardness assumption|problems]]. Early public-key systems, such as [[RSA_(cryptosystem)|RSA]]'s 1983 patent, based their security on the assumption that it is difficult to [[Integer factorization|factor]] a large integer composed of two or more large prime factors which are far apart. For | [[Public-key cryptography]] is based on the [[Intractability (complexity)#Intractability|intractability]] of certain mathematical [[Computational hardness assumption|problems]]. Early public-key systems, such as [[RSA_(cryptosystem)|RSA]]'s 1983 patent, based their security on the assumption that it is difficult to [[Integer factorization|factor]] a large integer composed of two or more large prime factors which are far apart. For elliptic-curve protocols, a central hardness assumption is the [[elliptic curve discrete logarithm problem]] (ECDLP): given a public base point <math>P</math> and another point <math>Q=kP</math>, it should be infeasible to recover <math>k</math>. Key-agreement protocols such as ECDH rely on related Diffie–Hellman assumptions, such as the difficulty of computing <math>abP</math> from <math>P</math>, <math>aP</math>, and <math>bP</math>. The security of elliptic curve cryptography depends on the ability to compute [[elliptic curve point multiplication|point multiplication]] efficiently and the apparent inability to reverse it for properly chosen curves and key sizes. The size and structure of the curve group, rather than only the total number of coordinate pairs satisfying the curve equation, determine the difficulty of the problem. | ||
The primary benefit promised by elliptic curve cryptography over alternatives such as RSA is a smaller [[key size]], reducing storage and transmission requirements.<ref name=":0" /> For example, a 256-bit elliptic curve public key should provide [[Security level|comparable security]] to a 3072-bit RSA public key. | The primary benefit promised by elliptic curve cryptography over alternatives such as RSA is a smaller [[key size]], reducing storage and transmission requirements.<ref name=":0" /> For example, a 256-bit elliptic curve public key should provide [[Security level|comparable security]] to a 3072-bit RSA public key. | ||
=== Cryptographic schemes === | === Cryptographic schemes === | ||
Several [[discrete logarithm]]-based protocols have been adapted to elliptic curves, replacing the group <math>(\mathbb{Z}_{p})^\times</math> with an elliptic curve: | Several [[discrete logarithm]]-based protocols have been adapted to elliptic curves, replacing the group <math>(\mathbb{Z}_{p})^\times</math> with an elliptic-curve group: | ||
* The [[Elliptic-curve Diffie–Hellman]] (ECDH) key agreement scheme is based on the [[Diffie–Hellman]] scheme, | * The [[Elliptic-curve Diffie–Hellman]] (ECDH) key agreement scheme is based on the [[Diffie–Hellman]] scheme, | ||
* [[Curve25519|X25519]] and [[Curve448|X448]] are Diffie–Hellman functions specified by the IRTF for use with Montgomery-form curves,<ref name="rfc7748">{{cite IETF |title=Elliptic Curves for Security |rfc=7748 |last1=Langley |first1=Adam |last2=Hamburg |first2=Mike |last3=Turner |first3=Sean |date=January 2016}}</ref> | |||
* The Elliptic Curve [[Integrated Encryption Scheme]] (ECIES), also known as Elliptic Curve Augmented Encryption Scheme or simply the Elliptic Curve Encryption Scheme, | * The Elliptic Curve [[Integrated Encryption Scheme]] (ECIES), also known as Elliptic Curve Augmented Encryption Scheme or simply the Elliptic Curve Encryption Scheme, | ||
* The [[Elliptic Curve Digital Signature Algorithm]] (ECDSA) is based on the [[Digital Signature Algorithm]], | * The [[Elliptic Curve Digital Signature Algorithm]] (ECDSA) is based on the [[Digital Signature Algorithm]], | ||
* The [[EdDSA|Edwards-curve Digital Signature Algorithm]] (EdDSA) is based on [[Schnorr signature]] and uses [[twisted Edwards curve]]s,<ref name="rfc8032">{{cite IETF |title=Edwards-Curve Digital Signature Algorithm (EdDSA) |rfc=8032 |last1=Josefsson |first1=Simon |last2=Liusvaara |first2=Ilari |date=January 2017}}</ref> | |||
* The [[EdDSA|Edwards-curve Digital Signature Algorithm]] (EdDSA) is based on [[Schnorr signature]] and uses [[twisted Edwards curve]]s, | |||
* The [[ECMQV]] key agreement scheme is based on the [[Menezes–Qu–Vanstone|MQV]] key agreement scheme, | * The [[ECMQV]] key agreement scheme is based on the [[Menezes–Qu–Vanstone|MQV]] key agreement scheme, | ||
* The [[Implicit certificate|ECQV]] implicit certificate scheme. | * The [[Implicit certificate|ECQV]] implicit certificate scheme. | ||
| Line 61: | Line 58: | ||
=== Domain parameters === | === 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 | 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 <math>\mathbb{F}_p</math>, or a binary field, denoted <math>\mathbb{F}_{2^m}</math>. In the binary case, <math>m</math> and an irreducible reduction polynomial <math>f</math> specify the field representation; <math>f</math> 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 [[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}_q)</math>, it follows from [[Lagrange's theorem (group theory)|Lagrange's theorem]] that the number <math>h = \frac{1}{n}|E(\mathbb{F}_q)|</math> is an integer. In cryptographic applications, this number ''h'', called the ''cofactor'', is usually small, ideally 1. Protocols using curves with cofactors greater than 1 must handle the cofactor appropriately. 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--> | 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: | 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/ | * [[NIST]], [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf SP 800-186: Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters]<ref name="nist-sp800186" /> | ||
* [[SECG]], [http://www.secg.org/sec2-v2.pdf SEC 2: Recommended Elliptic Curve Domain Parameters] | * [[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] | {{anchor|ECC Brainpool}} | ||
* ECC Brainpool ({{IETF RFC|5639}}), [http://www.ecc-brainpool.org/download/Domain-parameters.pdf ECC Brainpool Standard Curves and Curve Generation] {{Webarchive|url=https://web.archive.org/web/20180417212206/http://www.ecc-brainpool.org/download/Domain-parameters.pdf |date=2018-04-17 }}<ref>{{Cite web |url=http://www.ecc-brainpool.org/download/Domain-parameters.pdf |title=Archived copy |access-date=2012-04-12 |archive-date=2018-04-17 |archive-url=https://web.archive.org/web/20180417212206/http://www.ecc-brainpool.org/download/Domain-parameters.pdf |url-status=dead }}</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. | 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. | ||
| Line 79: | Line 77: | ||
* 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 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 ''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> | * 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 |archive-date=2017-09-21 |access-date=2017-10-28 |archive-url=https://web.archive.org/web/20170921213318/http://www.hpl.hp.com/techreports/97/HPL-97-128.ps |url-status=dead }}</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 === | === Key sizes === | ||
| Line 86: | Line 84: | ||
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. | 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. | ||
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.<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> The binary-field ECC2K-130 challenge has also been targeted by distributed computation using CPUs, GPUs, and FPGAs.<ref>{{cite web|url=http://www.ecc-challenge.info/|title=Breaking ECC2K-130|website=www.ecc-challenge.info}}</ref> | |||
=== Projective coordinates === | === 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> | 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 | === 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]], 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. | 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 <math>p \approx 2^d</math>; for example, <math>p = 2^{521} - 1</math> (P-521) or <math>p = 2^{256} - 2^{32} - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1.</math> (P-256) 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 | The curves over <math>\mathbb{F}_p</math> 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 [[Tanja Lange|Lange]] have criticized some design choices of the NIST curves and list alternative criteria for curve selection in the SafeCurves project.<ref name=SafeCurves>{{ 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> | ||
Other widely deployed curves also use primes with special forms that allow efficient reduction, such as <math>p = 2^{255} - 19</math> for Curve25519 and <math>2^{448} - 2^{224} - 1</math> for Curve448.<ref name=SafeCurves/> | |||
== Security == | == Security == | ||
=== Side-channel attacks === | === Side-channel attacks === | ||
Unlike most other [[ | Unlike most other [[discrete logarithm problem]] (DLP) systems (where it is possible to use the same procedure for squaring and multiplication), the EC addition is significantly different for doubling (''P'' = ''Q'') and general addition (''P'' ≠ ''Q'') depending on the coordinate system used. Consequently, it is important to counteract [[side-channel attack]]s (e.g., timing or [[Power analysis|simple/differential power analysis attacks]]) using, for example, fixed pattern window (a.k.a. comb) methods{{clarify|date=December 2011}}<ref>{{cite report |first1=M. |last1=Hedabou |first2=P. |last2=Pinel |first3=L. |last3=Beneteau |url=http://eprint.iacr.org/2004/342.pdf |title=A comb method to render ECC resistant against Side Channel Attacks |year=2004 |publisher=IACR Cryptology ePrint Archive}}</ref> (note that this does not increase computation time). Alternatively one can use an [[Edwards curve]]; this is a special family of elliptic curves for which doubling and addition can be done with the same operation.<ref>{{cite web | url=http://blog.cr.yp.to/20140323-ecdsa.html | title=Cr.yp.to: 2014.03.23: How to design an elliptic-curve signature system}}</ref> Another concern for ECC-systems is the danger of [[Differential fault analysis|fault attacks]], especially when running on [[smart card]]s.<ref>See, for example, {{Cite book |first1=Ingrid |last1=Biehl |first2=Bernd |last2=Meyer |first3=Volker |last3=Müller |title=Advances in Cryptology — CRYPTO 2000 |chapter=Differential Fault Attacks on Elliptic Curve Cryptosystems |series=[[Lecture Notes in Computer Science]] |volume=1880 |year=2000 |pages=131–146 |doi=10.1007/3-540-44598-6_8 |isbn=978-3-540-67907-3 |url=http://www.iacr.org/archive/crypto2000/18800131/18800131.pdf }}</ref> | ||
=== Backdoors === | === Backdoors === | ||
Cryptographic experts have expressed concerns that the [[National Security Agency]] has inserted a [[kleptographic]] backdoor into at least one elliptic curve-based pseudo random generator.<ref>[https://www.schneier.com/essay-198.html "Did NSA Put a Secret Backdoor in New Encryption Standard?"]. ''www.schneier.com''.</ref> Internal memos leaked by former NSA contractor [[Edward Snowden]] suggest that the NSA put a backdoor in the [[Dual EC DRBG]] standard.<ref>{{Cite web|title = Government Announces Steps to Restore Confidence on Encryption Standards|url = http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/|website = NY Times – Bits Blog|access-date = 2015-11-06|date = 2013-09-10}}</ref> One analysis of the possible backdoor concluded that an adversary in possession of the algorithm's secret key could obtain encryption keys given only 32 bytes of PRNG output.<ref>{{Cite web |last1=Shumow |first1=Dan |last2=Ferguson |first2=Niels |title=On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng |url=http://rump2007.cr.yp.to/15-shumow.pdf |website=Microsoft}}</ref> | Cryptographic experts have expressed concerns that the [[National Security Agency]] has inserted a [[kleptographic]] backdoor into at least one elliptic curve-based pseudo random generator.<ref>[https://www.schneier.com/essay-198.html "Did NSA Put a Secret Backdoor in New Encryption Standard?"]. ''www.schneier.com''.</ref> Internal memos leaked by former NSA contractor [[Edward Snowden]] suggest that the NSA put a backdoor in the [[Dual EC DRBG]] standard.<ref>{{Cite web|title = Government Announces Steps to Restore Confidence on Encryption Standards|url = http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/|website = NY Times – Bits Blog|access-date = 2015-11-06|date = 2013-09-10}}</ref> One analysis of the possible backdoor concluded that an adversary in possession of the algorithm's secret key could obtain encryption keys given only 32 bytes of PRNG output.<ref>{{Cite web |last1=Shumow |first1=Dan |last2=Ferguson |first2=Niels |title=On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng |url=http://rump2007.cr.yp.to/15-shumow.pdf |website=Microsoft}}</ref> | ||
The SafeCurves project | The SafeCurves project catalogs curves that are easy to implement securely and are designed in a fully publicly verifiable way to minimize the chance of a backdoor.<ref>{{Cite web | url = http://safecurves.cr.yp.to/ | title = SafeCurves: choosing safe curves for elliptic-curve cryptography | first1 = Daniel J. | last1 = Bernstein | first2 = Tanja | last2 = Lange | access-date = October 1, 2016}}</ref> | ||
=== Quantum computing attack === | === Quantum computing attack === | ||
[[Shor's algorithm]] can be used to break elliptic curve cryptography by computing discrete logarithms on a | [[Shor's algorithm]] can be used to break elliptic curve cryptography by computing discrete logarithms on a sufficiently large fault-tolerant [[Quantum computing|quantum computer]]. Published quantum resource estimates for breaking a curve with a 256-bit modulus (128-bit security level) include 2330 logical [[qubits]] and 126 billion [[Toffoli gate]]s.<ref>{{Cite arXiv |eprint=1706.06752 |last1=Roetteler |first1=Martin |title=Quantum resource estimates for computing elliptic curve discrete logarithms |last2=Naehrig |first2=Michael |last3=Svore |first3=Krysta M.|author3-link= Krysta Svore |last4=Lauter |first4=Kristin |class=quant-ph |year=2017 }}</ref> For the binary elliptic curve case, 906 logical qubits are necessary to break 128 bits of security.<ref>{{cite journal | ||
| last1 = Banegas | first1 = Gustavo | | last1 = Banegas | first1 = Gustavo | ||
| last2 = Bernstein | first2 = Daniel J. | | last2 = Bernstein | first2 = Daniel J. | ||
| Line 123: | Line 119: | ||
| volume = 2021 | | volume = 2021 | ||
| year = 2021| doi-access = free | | year = 2021| doi-access = free | ||
}}</ref> In | }}</ref> These estimates do not imply that current quantum computers can break deployed ECC systems, but they are a reason for migration planning. | ||
In August 2024, NIST approved the first three Federal Information Processing Standards for [[post-quantum cryptography]]: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA.<ref name="nist-pqc-fips">{{cite web |title=Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography |publisher=[[National Institute of Standards and Technology]] |date=13 August 2024 |url=https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved |access-date=30 April 2026}}</ref> NIST describes these standards as principal post-quantum standards for key establishment and digital signatures.<ref name="nist-pqc-project">{{cite web |title=Post-Quantum Cryptography |publisher=[[National Institute of Standards and Technology]] |url=https://csrc.nist.gov/projects/post-quantum-cryptography |access-date=30 April 2026}}</ref> NSA's CNSA 2.0 guidance similarly identifies quantum-resistant algorithms for national security systems and states that CNSA 1.0 compliance remains required during the transition.<ref name="nsa-cnsa2" /> | |||
[[Supersingular isogeny key exchange|Supersingular Isogeny Diffie–Hellman Key Exchange]] | [[Supersingular isogeny key exchange|Supersingular Isogeny Diffie–Hellman Key Exchange]] was proposed as a [[Post-quantum cryptography|post-quantum]] form of elliptic-curve-based key exchange using [[isogenies]].<ref>{{cite web|last=De Feo|first=Luca|title=Towards quantum-resistant cryptosystems from supersingular elliptic curve isogenies|url=https://eprint.iacr.org/2011/506|work=Cryptology ePrint Archive, Report 2011/506|publisher=IACR|access-date=3 May 2014|author2=Jao, Plut|archive-url=https://web.archive.org/web/20140503190338/http://eprint.iacr.org/2011/506|archive-date=2014-05-03|url-status=dead|year=2011}}</ref> However, new classical attacks undermined the security of this protocol.<ref>{{Cite journal |last=Robert |first=Damien |date=2022 |title=Breaking SIDH in polynomial time |url=https://eprint.iacr.org/2022/1038 |journal=Cryptology ePrint Archive |language=en}}</ref> | ||
In August 2015, the NSA announced that it planned to transition "in the not distant future" to a new cipher suite that is resistant to [[quantum computing|quantum]] attacks. "Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, necessitating a re-evaluation of our cryptographic strategy."<ref name="nsaquantum">{{cite web|url=https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm|title=Commercial National Security Algorithm Suite|date=19 August 2015|website=www.nsa.gov|url-status=live|archive-url=https://web.archive.org/web/20190604080321/https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm|archive-date=2019-06-04|access-date=2020-01-08}}</ref> | In August 2015, the NSA announced that it planned to transition "in the not distant future" to a new cipher suite that is resistant to [[quantum computing|quantum]] attacks. "Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, necessitating a re-evaluation of our cryptographic strategy."<ref name="nsaquantum">{{cite web|url=https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm|title=Commercial National Security Algorithm Suite|date=19 August 2015|website=www.nsa.gov|url-status=live|archive-url=https://web.archive.org/web/20190604080321/https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm|archive-date=2019-06-04|access-date=2020-01-08}}</ref> | ||
| Line 131: | Line 129: | ||
=== Invalid curve attack === | === Invalid curve attack === | ||
ECC implementations can be susceptible to invalid-curve attacks if they multiply a secret scalar by attacker-supplied points without verifying that the points lie on the intended curve and in the correct subgroup. In such attacks, repeated operations on invalid or small-order points can leak information about the private scalar. In 2019, an invalid-curve attack against AMD Secure Encrypted Virtualization was reported to recover a Platform Diffie–Hellman (PDH) private key.<ref name = "Cohen, Seclist, 2019" >{{ cite web | url = https://seclists.org/fulldisclosure/2019/Jun/46 | title = AMD-SEV: Platform DH key recovery via invalid curve attack (CVE-2019-9836) | access-date = 4 July 2019 | first = Cfir | last = Cohen | date = 25 June 2019 | website = Seclist Org | quote = The SEV elliptic-curve (ECC) implementation was found to be vulnerable to an invalid curve attack. At launch-start command, an attacker can send small order ECC points not on the official NIST curves, and force the SEV firmware to multiply a small order point by the firmware’s private DH scalar. | archive-url = https://web.archive.org/web/20190702011957/https://seclists.org/fulldisclosure/2019/Jun/46 | archive-date = 2 July 2019 | df = dmy-all }}</ref> | |||
== Alternative representations == | == Alternative representations == | ||
| Line 147: | Line 145: | ||
== See also == | == See also == | ||
{{Div col|colwidth=20em}} | {{Div col|colwidth=20em}} | ||
* [[ | * [[BLS digital signature]] | ||
* [[Curve25519]] | * [[Curve25519]] | ||
* [[DNSCurve]] | * [[DNSCurve]] | ||
* [[ECC patents]] | * [[ECC patents]] | ||
* [[ | * [[ECMQV]] | ||
* [[EdDSA]] | |||
* [[Elliptic Curve Digital Signature Algorithm]] (ECDSA) | * [[Elliptic Curve Digital Signature Algorithm]] (ECDSA) | ||
* [[Elliptic curve point multiplication]] | * [[Elliptic curve point multiplication]] | ||
* [[Elliptic-curve Diffie–Hellman]] (ECDH) | |||
* [[FourQ]] | |||
* [[Homomorphic signatures for network coding]] | * [[Homomorphic signatures for network coding]] | ||
* [[Hyperelliptic curve cryptography]] | * [[Hyperelliptic curve cryptography]] | ||
| Line 163: | Line 160: | ||
* [[Public-key cryptography]] | * [[Public-key cryptography]] | ||
* [[Quantum cryptography]] | * [[Quantum cryptography]] | ||
* [[RSA (cryptosystem)]] | |||
* [[Supersingular isogeny key exchange]] | * [[Supersingular isogeny key exchange]] | ||
{{Div col end}} | {{Div col end}} | ||
Latest revision as of 02:37, 19 May 2026
Elliptic-curve cryptography (ECC) is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC allows smaller keys to provide equivalent security, compared to cryptosystems based on modular exponentiation in finite fields, such as the RSA cryptosystem and ElGamal cryptosystem.[1]
Elliptic curves are applicable for key agreement, digital signatures, pseudo-random generators and other tasks. Indirectly, they can be used for encryption by combining the key agreement with a symmetric encryption scheme. They are also used in several integer factorization algorithms that have applications in cryptography, such as Lenstra elliptic-curve factorization.
History
TemplateStyles' src attribute must not be empty.
| [icon] | This section needs expansion with: a global view that expands coverage to include non-U.S. standards and standards bodies. You can help by adding to it. (March 2026) |
![[icon]](/w/index.php?title=Special:Upload&wpDestFile=Wiki_letter_w_cropped.svg){kind=link}
The use of elliptic curves in cryptography was suggested independently by Neal Koblitz[2] and Victor S. Miller[3] in 1985. Elliptic curve cryptography algorithms entered wide use starting in 2004.
In 1999, U.S. NIST recommended fifteen elliptic curves for use in the Digital Signature Standard. These curves were later specified in FIPS 186-4, which was superseded by FIPS 186-5 in 2023 and withdrawn in 2024.[4] NIST moved its recommended elliptic-curve domain parameters to Special Publication 800-186. SP 800-186 includes previously recommended Weierstrass curves and two Edwards curves for EdDSA; it also deprecates binary-field curves and strongly recommends use of prime curves.[5][6]
At the RSA Conference 2005, the National Security Agency (NSA) announced Suite B, which used ECC for digital signature generation and key exchange.[1] Suite B was later superseded by the Commercial National Security Algorithm Suite (CNSA), and NSA announced CNSA 2.0 as a quantum-resistant transition suite for national security systems.[7]
Since the early 2000s, cryptographic primitives based on bilinear mappings on various elliptic curve groups, such as the Weil and Tate pairings, have been studied. Schemes based on these primitives include identity-based encryption as well as pairing-based signatures, signcryption, key agreement, and proxy re-encryption.[8]
Elliptic curve cryptography is used successfully in numerous popular protocols, such as Transport Layer Security and Bitcoin.
Security concerns
In 2013, The New York Times stated that Dual Elliptic Curve Deterministic Random Bit Generation (or Dual_EC_DRBG) had been included as a NIST national standard due to the influence of NSA, which had included a deliberate weakness in the algorithm and the recommended elliptic curve.[9] RSA Security in September 2013 issued an advisory recommending that its customers discontinue using any software based on Dual_EC_DRBG.[10][11] In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover operation", cryptography experts have also expressed concern over the security of the NIST recommended elliptic curves,[12] suggesting a return to encryption based on non-elliptic-curve groups.
Additionally, in August 2015, the NSA announced that it planned to replace Suite B with a new cipher suite due to concerns about quantum computing attacks on ECC.[13][14] NSA later published CNSA 2.0 guidance for a transition to quantum-resistant algorithms for national security systems.[7]
Patents
While the RSA patent expired in 2000, there may be patents in force covering certain aspects of ECC technology, including at least one ECC scheme (ECMQV). However, RSA Laboratories[15] and Daniel J. Bernstein[16] have argued that the US government elliptic curve digital signature standard (ECDSA; NIST FIPS 186-3) and certain practical ECC-based key exchange schemes (including ECDH) can be implemented without infringing those patents.
Elliptic curve theory
For the purposes of this article, an elliptic curve is a plane curve over a finite field (rather than the real numbers). A common form for curves over finite fields of characteristic not equal to 2 or 3 consists of the points satisfying the equation
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle y^2 = x^3 + ax + b,}
along with a distinguished point at infinity, denoted ∞. Curves over fields of characteristic 2 or 3, and curves used in other representations such as Montgomery or Edwards form, are written differently.
This set of points, together with the group operation of elliptic curves, is an abelian group, with the point at infinity as an identity element. The structure of the group is inherited from the divisor group of the underlying algebraic variety:
- Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \operatorname{Div}^0(E) \to \operatorname{Pic}^0(E) \simeq E.}
Application to cryptography
Public-key cryptography is based on the intractability of certain mathematical problems. Early public-key systems, such as RSA's 1983 patent, based their security on the assumption that it is difficult to factor a large integer composed of two or more large prime factors which are far apart. For elliptic-curve protocols, a central hardness assumption is the elliptic curve discrete logarithm problem (ECDLP): given a public base point Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle P} and another point Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle Q=kP} , it should be infeasible to recover Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle k} . Key-agreement protocols such as ECDH rely on related Diffie–Hellman assumptions, such as the difficulty of computing Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle abP} from Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle P} , Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle aP} , and Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle bP} . The security of elliptic curve cryptography depends on the ability to compute point multiplication efficiently and the apparent inability to reverse it for properly chosen curves and key sizes. The size and structure of the curve group, rather than only the total number of coordinate pairs satisfying the curve equation, determine the difficulty of the problem.
The primary benefit promised by elliptic curve cryptography over alternatives such as RSA is a smaller key size, reducing storage and transmission requirements.[1] For example, a 256-bit elliptic curve public key should provide comparable security to a 3072-bit RSA public key.
Cryptographic schemes
Several discrete logarithm-based protocols have been adapted to elliptic curves, replacing the group Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (\mathbb{Z}_{p})^\times} with an elliptic-curve group:
- The Elliptic-curve Diffie–Hellman (ECDH) key agreement scheme is based on the Diffie–Hellman scheme,
- X25519 and X448 are Diffie–Hellman functions specified by the IRTF for use with Montgomery-form curves,[17]
- The Elliptic Curve Integrated Encryption Scheme (ECIES), also known as Elliptic Curve Augmented Encryption Scheme or simply the Elliptic Curve Encryption Scheme,
- The Elliptic Curve Digital Signature Algorithm (ECDSA) is based on the Digital Signature Algorithm,
- The Edwards-curve Digital Signature Algorithm (EdDSA) is based on Schnorr signature and uses twisted Edwards curves,[18]
- The ECMQV key agreement scheme is based on the MQV key agreement scheme,
- The ECQV implicit certificate scheme.
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 underlying finite field is typically either a prime field, denoted Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_p} , or a binary field, denoted Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_{2^m}} . In the binary case, Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle m} and an irreducible reduction polynomial Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle f} specify the field representation; Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle 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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle 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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle E(\mathbb{F}_q)} , it follows from Lagrange's theorem that the number Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle h = \frac{1}{n}|E(\mathbb{F}_q)|} is an integer. In cryptographic applications, this number h, called the cofactor, is usually small, ideally 1. Protocols using curves with cofactors greater than 1 must handle the cofactor appropriately. To summarize: in the prime case, the domain parameters are Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (p,a,b,G,n,h)} ; in the binary case, they are Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (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[6]
- SECG, SEC 2: Recommended Elliptic Curve Domain Parameters
- ECC Brainpool (RFC 5639), ECC Brainpool Standard Curves and Curve Generation Archived 2018-04-17 at the Wayback Machine[19][20]
SECG test vectors are also available.[21] 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.[22]
Several classes of curves are weak and should be avoided:
- Curves over Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_{2^m}} with non-prime m are vulnerable to Weil descent attacks.[23][24]
- Curves such that n divides Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle p^B-1} (where p is the characteristic of the field: q for a prime field, or Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle 2} for a binary field) for sufficiently small B are vulnerable to Menezes–Okamoto–Vanstone (MOV) attack[25][26] which applies usual discrete logarithm problem (DLP) in a small-degree extension field of Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_p} to solve ECDLP. The bound B should be chosen so that discrete logarithms in the field Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_{p^B}} are at least as difficult to compute as discrete logs on the elliptic curve Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle E(\mathbb{F}_q)} .[27]
- Curves such that Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle |E(\mathbb{F}_q)| = q} are vulnerable to the attack that maps the points on the curve to the additive group of Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_q} .[28][29][30]
Key sizes
Because all the fastest known algorithms that allow one to solve the ECDLP (baby-step giant-step, Pollard's rho, etc.), need Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle 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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_q} , where Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle q \approx 2^{256}} . This can be contrasted with finite-field cryptography (e.g., DSA) which requires[31] 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.[32] The binary field case was broken in April 2004 using 2600 computers over 17 months.[33] The binary-field ECC2K-130 challenge has also been targeted by distributed computation using CPUs, GPUs, and FPGAs.[34]
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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \mathbb{F}_q} but also an inversion operation. The inversion (for given Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle x \in \mathbb{F}_q} find Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle y \in \mathbb{F}_q} such that Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle x y = 1} ) is one to two orders of magnitude slower[35] 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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (X,Y,Z)} using the following relation: Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle x = \frac{X}{Z}} , Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle y = \frac{Y}{Z}} ; in the Jacobian system a point is also represented with three coordinates Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (X,Y,Z)} , but a different relation is used: Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle x = \frac{X}{Z^2}} , Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle y = \frac{Y}{Z^3}} ; in the López–Dahab system the relation is Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle x = \frac{X}{Z}} , Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle y = \frac{Y}{Z^2}} ; in the modified Jacobian system the same relations are used but four coordinates are stored and used for calculations Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (X,Y,Z,aZ^4)} ; and in the Chudnovsky Jacobian system five coordinates are used Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle (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.[36]
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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle p \approx 2^d} ; for example, Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle p = 2^{521} - 1} (P-521) or Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle 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.[37] 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 Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle \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.[38]
Other widely deployed curves also use primes with special forms that allow efficient reduction, such as Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle p = 2^{255} - 19} for Curve25519 and Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle 2^{448} - 2^{224} - 1} for Curve448.[38]
Security
Side-channel attacks
Unlike most other discrete logarithm problem (DLP) systems (where it is possible to use the same procedure for squaring and multiplication), the EC addition is significantly different for doubling (P = Q) and general addition (P ≠ Q) depending on the coordinate system used. Consequently, it is important to counteract side-channel attacks (e.g., timing or simple/differential power analysis attacks) using, for example, fixed pattern window (a.k.a. comb) methods[clarification needed][39] (note that this does not increase computation time). Alternatively one can use an Edwards curve; this is a special family of elliptic curves for which doubling and addition can be done with the same operation.[40] Another concern for ECC-systems is the danger of fault attacks, especially when running on smart cards.[41]
Backdoors
Cryptographic experts have expressed concerns that the National Security Agency has inserted a kleptographic backdoor into at least one elliptic curve-based pseudo random generator.[42] Internal memos leaked by former NSA contractor Edward Snowden suggest that the NSA put a backdoor in the Dual EC DRBG standard.[43] One analysis of the possible backdoor concluded that an adversary in possession of the algorithm's secret key could obtain encryption keys given only 32 bytes of PRNG output.[44]
The SafeCurves project catalogs curves that are easy to implement securely and are designed in a fully publicly verifiable way to minimize the chance of a backdoor.[45]
Quantum computing attack
Shor's algorithm can be used to break elliptic curve cryptography by computing discrete logarithms on a sufficiently large fault-tolerant quantum computer. Published quantum resource estimates for breaking a curve with a 256-bit modulus (128-bit security level) include 2330 logical qubits and 126 billion Toffoli gates.[46] For the binary elliptic curve case, 906 logical qubits are necessary to break 128 bits of security.[47] These estimates do not imply that current quantum computers can break deployed ECC systems, but they are a reason for migration planning.
In August 2024, NIST approved the first three Federal Information Processing Standards for post-quantum cryptography: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA.[48] NIST describes these standards as principal post-quantum standards for key establishment and digital signatures.[49] NSA's CNSA 2.0 guidance similarly identifies quantum-resistant algorithms for national security systems and states that CNSA 1.0 compliance remains required during the transition.[7]
Supersingular Isogeny Diffie–Hellman Key Exchange was proposed as a post-quantum form of elliptic-curve-based key exchange using isogenies.[50] However, new classical attacks undermined the security of this protocol.[51]
In August 2015, the NSA announced that it planned to transition "in the not distant future" to a new cipher suite that is resistant to quantum attacks. "Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, necessitating a re-evaluation of our cryptographic strategy."[13]
Invalid curve attack
ECC implementations can be susceptible to invalid-curve attacks if they multiply a secret scalar by attacker-supplied points without verifying that the points lie on the intended curve and in the correct subgroup. In such attacks, repeated operations on invalid or small-order points can leak information about the private scalar. In 2019, an invalid-curve attack against AMD Secure Encrypted Virtualization was reported to recover a Platform Diffie–Hellman (PDH) private key.[52]
Alternative representations
Alternative representations of elliptic curves include:
- Hessian curves
- Edwards curves
- Twisted curves
- Twisted Hessian curves
- Twisted Edwards curve
- Doubling-oriented Doche–Icart–Kohel curve
- Tripling-oriented Doche–Icart–Kohel curve
- Jacobian curve
- Montgomery curves
See also
- BLS digital signature
- Curve25519
- DNSCurve
- ECC patents
- ECMQV
- EdDSA
- Elliptic Curve Digital Signature Algorithm (ECDSA)
- Elliptic curve point multiplication
- Elliptic-curve Diffie–Hellman (ECDH)
- FourQ
- Homomorphic signatures for network coding
- Hyperelliptic curve cryptography
- Pairing-based cryptography
- Public-key cryptography
- Quantum cryptography
- RSA (cryptosystem)
- Supersingular isogeny key exchange
Notes
- ↑ 1.0 1.1 1.2 "The Case for Elliptic Curve Cryptography". NSA. Archived from the original on 2009-01-17.
- ↑ Koblitz, N. (1987). "Elliptic curve cryptosystems". Mathematics of Computation. 48 (177): 203–209. doi:10.2307/2007884. JSTOR 2007884.
- ↑ Miller, V. (1986). "Use of Elliptic Curves in Cryptography". Advances in Cryptology — CRYPTO '85 Proceedings. Lecture Notes in Computer Science. 85. pp. 417–426. doi:10.1007/3-540-39799-X_31. ISBN 978-3-540-16463-0. S2CID 206617984.
- ↑ "FIPS 186-4, Digital Signature Standard (DSS)". National Institute of Standards and Technology. Retrieved 30 April 2026.
- ↑ "NIST Releases FIPS 186-5 and SP 800-186". National Institute of Standards and Technology. 3 February 2023. Retrieved 30 April 2026.
- ↑ 6.0 6.1 Chen, Lily; Moody, Dustin; Regenscheid, Andrew; Randall, Karen (February 2023). Recommendations for Discrete Logarithm-Based Cryptography: Elliptic Curve Domain Parameters (PDF) (Report). National Institute of Standards and Technology. doi:10.6028/NIST.SP.800-186. NIST SP 800-186.
- ↑ 7.0 7.1 7.2 "NSA Releases Future Quantum-Resistant Algorithm Requirements for National Security Systems". National Security Agency. 7 September 2022. Retrieved 30 April 2026.
- ↑ Boneh, Dan; Franklin, Matthew (2003). "Identity-based encryption from the Weil pairing". SIAM Journal on Computing. 32 (3): 586–615. doi:10.1137/S0097539701398521.
- ↑ Perlroth, Nicole; Larson, Jeff; Shane, Scott (2013-09-05). "N.S.A. Able to Foil Basic Safeguards of Privacy on Web". New York Times. Archived from the original on 2022-01-01. Retrieved 28 October 2018.
- ↑ Kim Zetter, RSA Tells Its Developer Customers: Stop Using NSA-Linked Algorithm Wired, 19 September 2013. "Recommending against the use of SP 800-90A Dual Elliptic Curve Deterministic Random Bit Generation: NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A, no longer be used."
- ↑ "Search – CSRC". csrc.nist.gov.
- ↑ Bruce Schneier (5 September) "I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry." See Are the NIST Standard Elliptic Curves Back-doored?, Slashdot, 11 September 2013.
- ↑ 13.0 13.1 "Commercial National Security Algorithm Suite". www.nsa.gov. 19 August 2015. Archived from the original on 2019-06-04. Retrieved 2020-01-08.
- ↑ Commercial National Security Algorithm Suite and Quantum Computing FAQ U.S. National Security Agency, January 2016.
- ↑ RSA Laboratories. "6.3.4 Are elliptic curve cryptosystems patented?". Archived from the original on 2016-11-01.
- ↑ Bernstein, D. J. "Irrelevant patents on elliptic-curve cryptography".
- ↑ Template:Cite IETF
- ↑ Template:Cite IETF
- ↑ "Archived copy" (PDF). Archived from the original (PDF) on 2018-04-17. Retrieved 2012-04-12.CS1 maint: archived copy as title (link)
- ↑ "Elliptic Curve Cryptography "Made in Germany"" (Press release). 2014-06-25.
- ↑ "GEC 2: Test Vectors for SEC 1" (PDF). www.secg.org. Archived from the original (PDF download) on 2013-06-06.
- ↑ Lay, Georg-Johann; Zimmer, Horst G. (1994). "Constructing elliptic curves with given group order over large finite fields". Algorithmic Number Theory. Lecture Notes in Computer Science. 877. pp. 250–263. doi:10.1007/3-540-58691-1_64. ISBN 978-3-540-58691-3.
- ↑ Galbraith, S. D.; Smart, N. P. (1999). "A Cryptographic Application of Weil Descent". A cryptographic application of the Weil descent. Lecture Notes in Computer Science. 1746. p. 799. doi:10.1007/3-540-46665-7_23. ISBN 978-3-540-66887-9. S2CID 15134380.
- ↑ Gaudry, P.; Hess, F.; Smart, N. P. (2000). "Constructive and destructive facets of Weil descent on elliptic curves" (PDF). Hewlett Packard Laboratories Technical Report. Archived from the original (PDF) on 2006-12-06. Retrieved 2006-01-02.
- ↑ Menezes, A.; Okamoto, T.; Vanstone, S. A. (1993). "Reducing elliptic curve logarithms to logarithms in a finite field". IEEE Transactions on Information Theory. 39 (5): 1639–1646. doi:10.1109/18.259647.
- ↑ Hitt, L. (2006). "On an Improved Definition of Embedding Degree". IACR ePrint Report. 415.
- ↑ IEEE P1363 Archived 2007-02-13 at the Wayback Machine, section A.12.1
- ↑ Semaev, I. (1998). "Evaluation of discrete logarithm in a group of p-torsion points of an elliptic curve in characteristic p". Mathematics of Computation. 67 (221): 353–356. Bibcode:1998MaCom..67..353S. doi:10.1090/S0025-5718-98-00887-4.
- ↑ Smart, N. (1999). "The discrete logarithm problem on elliptic curves of trace one". Journal of Cryptology. 12 (3): 193–196. CiteSeerX 10.1.1.17.1880. doi:10.1007/s001459900052. S2CID 24368962. Archived from the original on 2017-09-21. Retrieved 2017-10-28.
- ↑ Satoh, T.; Araki, K. (1998). "Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves". Commentarii Mathematici Universitatis Sancti Pauli. 47.
- ↑ NIST, Recommendation for Key Management—Part 1: general, Special Publication 800-57, August 2005.
- ↑ "112-bit prime ECDLP solved – LACAL". lacal.epfl.ch. Archived from the original on 2009-07-15. Retrieved 2009-07-11.
- ↑ "Certicom Announces Elliptic Curve Cryptography Challenge Winner". Certicom. April 27, 2004. Archived from the original on 2011-07-19.
- ↑ "Breaking ECC2K-130". www.ecc-challenge.info.
- ↑ Hitchcock, Y.; Dawson, E.; Clark, A.; Montague, P. (2002). "Implementing an efficient elliptic curve cryptosystem over GF(p) on a smart card" (PDF). ANZIAM Journal. 44. Archived from the original (PDF) on 2006-03-27.
- ↑ Cohen, H.; Miyaji, A.; Ono, T. (1998). "Efficient Elliptic Curve Exponentiation Using Mixed Coordinates". Advances in Cryptology — ASIACRYPT'98. Lecture Notes in Computer Science. 1514. pp. 51–65. doi:10.1007/3-540-49649-1_6. ISBN 978-3-540-65109-3.
- ↑ Brown, M.; Hankerson, D.; Lopez, J.; Menezes, A. (2001). "Software Implementation of the NIST Elliptic Curves over Prime Fields". Topics in Cryptology — CT-RSA 2001. Lecture Notes in Computer Science. 2020. pp. 250–265. CiteSeerX 10.1.1.25.8619. doi:10.1007/3-540-45353-9_19. ISBN 978-3-540-41898-6.
- ↑ 38.0 38.1 Daniel J. Bernstein & Tanja Lange. "SafeCurves: choosing safe curves for elliptic-curve cryptography". Retrieved 1 December 2013.
- ↑ Hedabou, M.; Pinel, P.; Beneteau, L. (2004). A comb method to render ECC resistant against Side Channel Attacks (PDF) (Report). IACR Cryptology ePrint Archive.
- ↑ "Cr.yp.to: 2014.03.23: How to design an elliptic-curve signature system".
- ↑ See, for example, Biehl, Ingrid; Meyer, Bernd; Müller, Volker (2000). "Differential Fault Attacks on Elliptic Curve Cryptosystems". Advances in Cryptology — CRYPTO 2000 (PDF). Lecture Notes in Computer Science. 1880. pp. 131–146. doi:10.1007/3-540-44598-6_8. ISBN 978-3-540-67907-3.
- ↑ "Did NSA Put a Secret Backdoor in New Encryption Standard?". www.schneier.com.
- ↑ "Government Announces Steps to Restore Confidence on Encryption Standards". NY Times – Bits Blog. 2013-09-10. Retrieved 2015-11-06.
- ↑ Shumow, Dan; Ferguson, Niels. "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng" (PDF). Microsoft.
- ↑ Bernstein, Daniel J.; Lange, Tanja. "SafeCurves: choosing safe curves for elliptic-curve cryptography". Retrieved October 1, 2016.
- ↑ Roetteler, Martin; Naehrig, Michael; Svore, Krysta M.; Lauter, Kristin (2017). "Quantum resource estimates for computing elliptic curve discrete logarithms". arXiv:1706.06752 [quant-ph].
- ↑ Banegas, Gustavo; Bernstein, Daniel J.; van Hoof, Iggy; Lange, Tanja (2021). "Concrete quantum cryptanalysis of binary elliptic curves". IACR Transactions on Cryptographic Hardware and Embedded Systems. 2021 (1): 451–472. doi:10.46586/TCHES.V2021.I1.451-472.
- ↑ "Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography". National Institute of Standards and Technology. 13 August 2024. Retrieved 30 April 2026.
- ↑ "Post-Quantum Cryptography". National Institute of Standards and Technology. Retrieved 30 April 2026.
- ↑ De Feo, Luca; Jao, Plut (2011). "Towards quantum-resistant cryptosystems from supersingular elliptic curve isogenies". Cryptology ePrint Archive, Report 2011/506. IACR. Archived from the original on 2014-05-03. Retrieved 3 May 2014.
- ↑ Robert, Damien (2022). "Breaking SIDH in polynomial time". Cryptology ePrint Archive.
- ↑ Cohen, Cfir (25 June 2019). "AMD-SEV: Platform DH key recovery via invalid curve attack (CVE-2019-9836)". Seclist Org. Archived from the original on 2 July 2019. Retrieved 4 July 2019.
The SEV elliptic-curve (ECC) implementation was found to be vulnerable to an invalid curve attack. At launch-start command, an attacker can send small order ECC points not on the official NIST curves, and force the SEV firmware to multiply a small order point by the firmware’s private DH scalar.
References
- Standards for Efficient Cryptography Group (SECG), SEC 1: Elliptic Curve Cryptography, Version 1.0, September 20, 2000. (archived as of Nov 11, 2014)
- D. Hankerson, A. Menezes, and S.A. Vanstone, Guide to Elliptic Curve Cryptography, Springer-Verlag, 2004.
- I. Blake, G. Seroussi, and N. Smart, Elliptic Curves in Cryptography, London Mathematical Society 265, Cambridge University Press, 1999.
- I. Blake, G. Seroussi, and N. Smart, editors, Advances in Elliptic Curve Cryptography, London Mathematical Society 317, Cambridge University Press, 2005.
- L. Washington, Elliptic Curves: Number Theory and Cryptography, Chapman & Hall / CRC, 2003.
- The Case for Elliptic Curve Cryptography, National Security Agency (archived January 17, 2009)
- Online Elliptic Curve Cryptography Tutorial, Certicom Corp. (archived here as of March 3, 2016)
- K. Malhotra, S. Gardner, and R. Patz, Implementation of Elliptic-Curve Cryptography on Mobile Healthcare Devices, Networking, Sensing and Control, 2007 IEEE International Conference on, London, 15–17 April 2007 Page(s):239–244
- Saikat Basu, A New Parallel Window-Based Implementation of the Elliptic Curve Point Multiplication in Multi-Core Architectures, International Journal of Network Security, Vol. 13, No. 3, 2011, Page(s):234–241 (archived here as of March 4, 2016)
- Christof Paar, Jan Pelzl, "Elliptic Curve Cryptosystems", Chapter 9 of "Understanding Cryptography, A Textbook for Students and Practitioners". (companion web site contains online cryptography course that covers elliptic curve cryptography), Springer, 2009. (archived here as of April 20, 2016)
- Luca De Feo, David Jao, Jerome Plut, Towards quantum-resistant cryptosystems from supersingular elliptic curve isogenies, Springer 2011. (archived here as of May 7, 2012)
- Gustavo Banegas, Daniel J. Bernstein, Iggy Van Hoof, Tanja Lange, Concrete quantum cryptanalysis of binary elliptic curves, Springer 2020. (archived here as of June 1, 2020)
External links
- Elliptic Curves at Stanford University
- Interactive introduction to elliptic curves and elliptic curve cryptography with Sage by Maike Massierer and the CrypTool team
- Template:Commons-inline
Template:Cryptography navbox Template:Algebraic curves navbox