Elliptic Curve Digital Signature Algorithm - Revision history

imported>Paul2520: Rescuing 15 sources and tagging 0 as dead.) #IABot (v2.0.9.5

2025-07-22T15:01:23Z

Rescuing 15 sources and tagging 0 as dead.) #IABot (v2.0.9.5

← Previous revision		Revision as of 15:01, 22 July 2025
Line 48:		Line 48:

	# Calculate <math>e = \textrm{HASH}(m)</math>. (Here HASH is a [[cryptographic hash function]], such as [[SHA-2]], with the output converted to an integer.)		# Calculate <math>e = \textrm{HASH}(m)</math>. (Here HASH is a [[cryptographic hash function]], such as [[SHA-2]], with the output converted to an integer.)
	# Let <math>z</math> be the <math>L_n</math> leftmost bits of <math>e</math>, where <math>L_n</math> is the bit length of the group order <math>n</math>. (Note that <math>z</math> can be ''greater'' than <math>n</math> but not ''longer''.<ref>		# Let <math>z</math> be the <math>L_n</math> leftmost bits of <math>e</math>, where <math>L_n</math> is the bit length of the group order <math>n</math>. (Note that <math>z</math> can be ''greater'' than <math>n</math> but not ''longer''.<ref>{{Cite web \|url=http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf \|title=NIST FIPS 186-4, July 2013, pp. 19 and 26 \|access-date=March 17, 2014 \|archive-date=December 27, 2016 \|archive-url=https://web.archive.org/web/20161227093019/http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf \|url-status=live }}</ref>)
	[http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf NIST FIPS 186-4, July 2013, pp. 19 and 26]</ref>)
	# Select a '''cryptographically secure random''' integer <math>k</math> from <math>[1, n-1]</math>.		# Select a '''cryptographically secure random''' integer <math>k</math> from <math>[1, n-1]</math>.
	# Calculate the curve point <math>(x_1, y_1) = k \times G</math>.		# Calculate the curve point <math>(x_1, y_1) = k \times G</math>.
Line 60:		Line 59:
	This implementation failure was used, for example, to extract the signing key used for the [[PlayStation 3]] gaming-console.<ref>[https://events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf Console Hacking 2010 - PS3 Epic Fail] {{Webarchive\|url=https://web.archive.org/web/20141215140847/http://events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf \|date=December 15, 2014 }}, page 123–128</ref>		This implementation failure was used, for example, to extract the signing key used for the [[PlayStation 3]] gaming-console.<ref>[https://events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf Console Hacking 2010 - PS3 Epic Fail] {{Webarchive\|url=https://web.archive.org/web/20141215140847/http://events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf \|date=December 15, 2014 }}, page 123–128</ref>

	Another way ECDSA signature may leak private keys is when <math>k</math> is generated by a faulty [[random number generator]]. Such a failure in random number generation caused users of Android Bitcoin Wallet to lose their funds in August 2013.<ref>{{cite web\|url=https://bitcoin.org/en/alert/2013-08-11-android\|title=Android Security Vulnerability\|access-date=February 24, 2015}}</ref>		Another way ECDSA signature may leak private keys is when <math>k</math> is generated by a faulty [[random number generator]]. Such a failure in random number generation caused users of Android Bitcoin Wallet to lose their funds in August 2013.<ref>{{cite web\|url=https://bitcoin.org/en/alert/2013-08-11-android\|title=Android Security Vulnerability\|access-date=February 24, 2015\|archive-date=April 7, 2019\|archive-url=https://web.archive.org/web/20190407170847/https://bitcoin.org/en/alert/2013-08-11-android\|url-status=live}}</ref>

	To ensure that <math>k</math> is unique for each message, one may bypass random number generation completely and generate deterministic signatures by deriving <math>k</math> from both the message and the private key.<ref>{{cite tech report\|url=https://www.rfc-editor.org/rfc/rfc6979.html\|title=RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)\|year=2013 \|doi=10.17487/RFC6979 \|access-date=February 24, 2015\|last1=Pornin \|first1=T. \|doi-access=free }}</ref>		To ensure that <math>k</math> is unique for each message, one may bypass random number generation completely and generate deterministic signatures by deriving <math>k</math> from both the message and the private key.<ref>{{cite tech report\|url=https://www.rfc-editor.org/rfc/rfc6979.html\|title=RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)\|year=2013 \|doi=10.17487/RFC6979 \|access-date=February 24, 2015\|last1=Pornin \|first1=T. \|doi-access=free }}</ref>
Line 80:		Line 79:
	# The signature is valid if <math>r \equiv x_1 \pmod{n}</math>, invalid otherwise.		# The signature is valid if <math>r \equiv x_1 \pmod{n}</math>, invalid otherwise.

	Note that an efficient implementation would compute inverse <math>s^{-1}\,\bmod\,n</math> only once. Also, using Shamir's trick, a sum of two scalar multiplications <math>u_1 \times G + u_2 \times Q_A</math> can be calculated faster than two scalar multiplications done independently.<ref>{{cite web \| url=http://www.lirmm.fr/~imbert/talks/laurent_Asilomar_08.pdf \| title=The Double-Base Number System in Elliptic Curve Cryptography \| access-date=22 April 2014}}</ref>		Note that an efficient implementation would compute inverse <math>s^{-1}\,\bmod\,n</math> only once. Also, using Shamir's trick, a sum of two scalar multiplications <math>u_1 \times G + u_2 \times Q_A</math> can be calculated faster than two scalar multiplications done independently.<ref>{{cite web \| url=http://www.lirmm.fr/~imbert/talks/laurent_Asilomar_08.pdf \| title=The Double-Base Number System in Elliptic Curve Cryptography \| access-date=22 April 2014 \| archive-date=July 26, 2011 \| archive-url=https://web.archive.org/web/20110726150643/http://www.lirmm.fr/~imbert/talks/laurent_Asilomar_08.pdf \| url-status=live }}</ref>

	===Correctness of the algorithm===		===Correctness of the algorithm===
Line 163:		Line 162:

	==Security==		==Security==
	In December 2010, a group calling itself ''fail0verflow'' announced the recovery of the ECDSA private key used by [[Sony]] to sign software for the [[PlayStation 3]] game console. However, this attack only worked because Sony did not properly implement the algorithm, because <math>k</math> was static instead of random. As pointed out in the [[#Signature generation algorithm\|Signature generation algorithm]] section above, this makes <math>d_A</math> solvable, rendering the entire algorithm useless.<ref>{{Cite news\|last=Bendel\|first=Mike\|title=Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access\|publisher=Exophase.com\|date=2010-12-29\|url=http://exophase.com/20540/hackers-describe-ps3-security-as-epic-fail-gain-unrestricted-access/\|access-date=2011-01-05}}</ref>		In December 2010, a group calling itself ''fail0verflow'' announced the recovery of the ECDSA private key used by [[Sony]] to sign software for the [[PlayStation 3]] game console. However, this attack only worked because Sony did not properly implement the algorithm, because <math>k</math> was static instead of random. As pointed out in the [[#Signature generation algorithm\|Signature generation algorithm]] section above, this makes <math>d_A</math> solvable, rendering the entire algorithm useless.<ref>{{Cite news\|last=Bendel\|first=Mike\|title=Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access\|publisher=Exophase.com\|date=2010-12-29\|url=http://exophase.com/20540/hackers-describe-ps3-security-as-epic-fail-gain-unrestricted-access/\|access-date=2011-01-05\|archive-date=April 7, 2019\|archive-url=https://web.archive.org/web/20190407174117/https://www.exophase.com/20540/hackers-describe-ps3-security-as-epic-fail-gain-unrestricted-access/\|url-status=live}}</ref>

	On March 29, 2011, two researchers published an [[International Association for Cryptologic Research\|IACR]] paper<ref>{{cite web\|url=http://eprint.iacr.org/2011/232\|title=Cryptology ePrint Archive: Report 2011/232\|access-date=February 24, 2015}}</ref> demonstrating that it is possible to retrieve a TLS private key of a server using [[OpenSSL]] that authenticates with Elliptic Curves DSA over a binary [[Field (mathematics)\|field]] via a [[timing attack]].<ref>{{cite web\|url=https://www.kb.cert.org/vuls/id/536044\|title=Vulnerability Note VU#536044 - OpenSSL leaks ECDSA private key through a remote timing attack\|website=www.kb.cert.org}}</ref> The vulnerability was fixed in OpenSSL 1.0.0e.<ref>{{cite web \| url=http://www.openssl.org/news/changelog.html \| title=ChangeLog \| publisher=OpenSSL Project \| access-date=22 April 2014}}</ref>		On March 29, 2011, two researchers published an [[International Association for Cryptologic Research\|IACR]] paper<ref>{{cite web\|url=http://eprint.iacr.org/2011/232\|title=Cryptology ePrint Archive: Report 2011/232\|access-date=February 24, 2015\|archive-date=December 8, 2018\|archive-url=https://web.archive.org/web/20181208115720/https://eprint.iacr.org/2011/232\|url-status=live}}</ref> demonstrating that it is possible to retrieve a TLS private key of a server using [[OpenSSL]] that authenticates with Elliptic Curves DSA over a binary [[Field (mathematics)\|field]] via a [[timing attack]].<ref>{{cite web\|url=https://www.kb.cert.org/vuls/id/536044\|title=Vulnerability Note VU#536044 - OpenSSL leaks ECDSA private key through a remote timing attack\|website=www.kb.cert.org\|access-date=May 24, 2011\|archive-date=April 7, 2019\|archive-url=https://web.archive.org/web/20190407195622/https://www.kb.cert.org/vuls/id/536044/\|url-status=live}}</ref> The vulnerability was fixed in OpenSSL 1.0.0e.<ref>{{cite web \| url=http://www.openssl.org/news/changelog.html \| title=ChangeLog \| publisher=OpenSSL Project \| access-date=22 April 2014 \| archive-date=August 9, 2020 \| archive-url=https://web.archive.org/web/20200809005201/https://www.openssl.org/news/changelog.html \| url-status=live }}</ref>

	In August 2013, it was revealed that bugs in some implementations of the [[Java (programming language)\|Java]] class [https://docs.oracle.com/javase/10/docs/api/java/security/SecureRandom.html SecureRandom] sometimes generated collisions in the <math>k</math> value. This allowed hackers to recover private keys giving them the same control over bitcoin transactions as legitimate keys' owners had, using the same exploit that was used to reveal the PS3 signing key on some [[Android (operating system)\|Android]] app implementations, which use Java and rely on ECDSA to authenticate transactions.<ref>{{cite web \|title=Android bug batters Bitcoin wallets		In August 2013, it was revealed that bugs in some implementations of the [[Java (programming language)\|Java]] class [https://docs.oracle.com/javase/10/docs/api/java/security/SecureRandom.html SecureRandom] sometimes generated collisions in the <math>k</math> value. This allowed hackers to recover private keys giving them the same control over bitcoin transactions as legitimate keys' owners had, using the same exploit that was used to reveal the PS3 signing key on some [[Android (operating system)\|Android]] app implementations, which use Java and rely on ECDSA to authenticate transactions.<ref>{{cite web
	\| url= https://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets/ \|publisher=The Register \|date=12 August 2013}}</ref>		\|title=Android bug batters Bitcoin wallets
			\|url=https://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets/
			\|publisher=The Register
			\|date=12 August 2013
			\|access-date=August 27, 2017
			\|archive-date=August 15, 2013
			\|archive-url=https://web.archive.org/web/20130815181104/http://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets
			\|url-status=live
			}}</ref>

	This issue can be prevented by deterministic generation of k, as described by RFC 6979.		This issue can be prevented by deterministic generation of k, as described by RFC 6979.
Line 175:		Line 182:
	Some concerns expressed about ECDSA:		Some concerns expressed about ECDSA:

	# ''Political concerns'': the trustworthiness of [[National Institute of Standards and Technology\|NIST]]-produced curves being questioned after revelations were made that the [[National Security Agency\|NSA]] willingly inserts [[Backdoor (computing)\|backdoors]] into software, hardware components and published standards; well-known cryptographers<ref>{{cite web\|url=https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929\|title=The NSA Is Breaking Most Encryption on the Internet\|website=Schneier on Security\|first=Bruce\|last=Schneier\|date=September 5, 2013}}</ref> have expressed<ref>{{cite web\|url=http://safecurves.cr.yp.to/rigid.html\|title=SafeCurves: choosing safe curves for elliptic-curve cryptography\|date=Oct 25, 2013}}</ref><ref>{{cite web\|url=https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf\|title=Security dangers of the NIST curves\|first1=Daniel J.\|last1=Bernstein\|first2=Tanja\|last2=Lange\|author2-link=Tanja Lange\|date=May 31, 2013}}</ref> doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past.<ref>{{cite web\|url=https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html\|title=The Strange Story of Dual_EC_DRBG\|website=Schneier on Security\|first=Bruce\|last=Schneier\|date=November 15, 2007}}</ref><ref>{{cite web\|url=http://www.scientificamerican.com/article/nsa-nist-encryption-scandal/\|title=NSA Efforts to Evade Encryption Technology Damaged U.S. Cryptography Standard\|first=Larry\|last=Greenemeier\|publisher=Scientific American\|date=September 18, 2013}}</ref> (See also the ''libssh [[curve25519]] introduction''.<ref>{{cite web\|url=https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4\|title=curve25519-sha256@libssh.org.txt\doc - projects/libssh.git\|website=libssh shared repository}}</ref>) Nevertheless, a proof that the named NIST curves exploit a rare weakness is still missing.		# ''Political concerns'': the trustworthiness of [[National Institute of Standards and Technology\|NIST]]-produced curves being questioned after revelations were made that the [[National Security Agency\|NSA]] willingly inserts [[Backdoor (computing)\|backdoors]] into software, hardware components and published standards; well-known cryptographers<ref>{{cite web\|url=https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929\|title=The NSA Is Breaking Most Encryption on the Internet\|website=Schneier on Security\|first=Bruce\|last=Schneier\|date=September 5, 2013\|access-date=January 11, 2018\|archive-date=December 15, 2017\|archive-url=https://web.archive.org/web/20171215132353/https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929\|url-status=live}}</ref> have expressed<ref>{{cite web\|url=http://safecurves.cr.yp.to/rigid.html\|title=SafeCurves: choosing safe curves for elliptic-curve cryptography\|date=Oct 25, 2013\|access-date=January 11, 2018\|archive-date=April 7, 2019\|archive-url=https://web.archive.org/web/20190407195617/http://safecurves.cr.yp.to/rigid.html\|url-status=live}}</ref><ref>{{cite web\|url=https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf\|title=Security dangers of the NIST curves\|first1=Daniel J.\|last1=Bernstein\|first2=Tanja\|last2=Lange\|author2-link=Tanja Lange\|date=May 31, 2013\|access-date=January 11, 2018\|archive-date=May 28, 2019\|archive-url=https://web.archive.org/web/20190528083030/https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf\|url-status=live}}</ref> doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past.<ref>{{cite web\|url=https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html\|title=The Strange Story of Dual_EC_DRBG\|website=Schneier on Security\|first=Bruce\|last=Schneier\|date=November 15, 2007\|access-date=January 11, 2018\|archive-date=April 23, 2019\|archive-url=https://web.archive.org/web/20190423212823/https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html\|url-status=live}}</ref><ref>{{cite web\|url=http://www.scientificamerican.com/article/nsa-nist-encryption-scandal/\|title=NSA Efforts to Evade Encryption Technology Damaged U.S. Cryptography Standard\|first=Larry\|last=Greenemeier\|publisher=Scientific American\|date=September 18, 2013\|access-date=January 11, 2018\|archive-date=December 24, 2017\|archive-url=https://web.archive.org/web/20171224213856/https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/\|url-status=live}}</ref> (See also the ''libssh [[curve25519]] introduction''.<ref>{{cite web\|url=https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4\|title=curve25519-sha256@libssh.org.txt\doc - projects/libssh.git\|website=libssh shared repository\|access-date=January 11, 2018\|archive-date=March 23, 2019\|archive-url=https://web.archive.org/web/20190323030904/https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4\|url-status=live}}</ref>) Nevertheless, a proof that the named NIST curves exploit a rare weakness is still missing.
	# ''Technical concerns'': the difficulty of properly implementing the standard, its slowness, and design flaws which reduce security in insufficiently defensive implementations.<ref>{{cite web\|url=http://blog.cr.yp.to/20140323-ecdsa.html\|title=How to design an elliptic-curve signature system\|first=Daniel J.\|last=Bernstein\|date=March 23, 2014\|website=The cr.yp.to blog}}</ref>		# ''Technical concerns'': the difficulty of properly implementing the standard, its slowness, and design flaws which reduce security in insufficiently defensive implementations.<ref>{{cite web\|url=http://blog.cr.yp.to/20140323-ecdsa.html\|title=How to design an elliptic-curve signature system\|first=Daniel J.\|last=Bernstein\|date=March 23, 2014\|website=The cr.yp.to blog\|access-date=January 11, 2018\|archive-date=March 23, 2014\|archive-url=https://web.archive.org/web/20140323220738/http://blog.cr.yp.to/20140323-ecdsa.html\|url-status=live}}</ref>

	== Implementations ==		== Implementations ==

109.61.8.190 at 08:53, 8 May 2025

2025-05-08T08:53:48Z

New page

{{Short description|Cryptographic

algorithm for digital signatures}}
{{Use mdy dates|date=April 2012}}
{{confused|EdDSA}}
In [[cryptography]], the '''Elliptic Curve Digital Signature Algorithm''' ('''ECDSA''') offers a variant of the [[Digital Signature Algorithm]] (DSA) which uses [[elliptic-curve cryptography]].

==Key and signature sizes==
As with elliptic-curve cryptography in general, the bit [[Key size|size]] of the [[private key]] believed to be needed for ECDSA is about twice the size of the [[security level]], in bits.<ref>{{cite journal
| title=The Elliptic Curve Digital Signature Algorithm (ECDSA)
| year=1999
| first1=Don
| last1=Johnson
| first2=Alfred
| last2=Menezes
| citeseerx=10.1.1.38.8014
| journal=Certicom Research. Canada
}}</ref> For example, at a security level of 80 bits—meaning an attacker requires a maximum of about <math>2^{80}</math> operations to find the private key—the size of an ECDSA private key would be 160 bits. On the other hand, the signature size is the same for both DSA and ECDSA: approximately <math>4 t</math> bits, where <math>t</math> is the exponent in the formula <math>2^{t}</math>, that is, about 320 bits for a security level of 80 bits, which is equivalent to <math>2^{80}</math> operations.

==Signature generation algorithm==
Suppose [[Alice and Bob|Alice]] wants to send a signed message to [[Alice and Bob|Bob]]. Initially, they must agree on the curve parameters <math>(\textrm{CURVE}, G, n)</math>. In addition to the [[Field_(mathematics)|field]] and equation of the curve, we need <math>G</math>, a base point of prime order on the curve; <math>n</math> is the additive order of the point <math>G</math>.

{| class="wikitable"
|-
! Parameter !!
|-z2*s1)/(r*(s1-s2))
| CURVE || the elliptic curve field and equation used
|-
| ''G'' || elliptic curve base point, a point on the curve that generates a [[Elliptic-curve_cryptography#Domain_parameters|subgroup of large prime order n]]
|-
| ''n'' || integer order of ''G'', means that <math>n \times G = O</math>, where <math>O</math> is the identity element.
|-
|<math>d_A</math>
|the private key (randomly selected)
|-
|<math>Q_A</math>
|the public key <math>d_A \times G</math> (calculated by elliptic curve)
|-
|''m''
|the message to send
|}

The order <math>n</math> of the base point <math>G</math> '''must be prime'''. Indeed, we assume that every nonzero element of the [[Ring_(mathematics)|ring]] <math>\mathbb{Z}/n\mathbb{Z}</math> is invertible, so that <math>\mathbb{Z}/n\mathbb{Z}</math> must be a [[Field (mathematics)|field]]. It implies that <math>n</math> must be prime (cf. [[Bézout's identity]]).

Alice creates a key pair, consisting of a private key integer <math>d_A</math>, randomly selected in the interval <math>[1, n-1]</math>; and a public key curve point <math>Q_A = d_A \times G</math>. We use <math>\times</math> to denote [[Elliptic curve point multiplication|elliptic curve point multiplication by a scalar]].

For Alice to sign a message <math>m</math>, she follows these steps:

# Calculate <math>e = \textrm{HASH}(m)</math>. (Here HASH is a [[cryptographic hash function]], such as [[SHA-2]], with the output converted to an integer.)
# Let <math>z</math> be the <math>L_n</math> leftmost bits of <math>e</math>, where <math>L_n</math> is the bit length of the group order <math>n</math>. (Note that <math>z</math> can be ''greater'' than <math>n</math> but not ''longer''.<ref>
[http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf NIST FIPS 186-4, July 2013, pp. 19 and 26]</ref>)
# Select a '''cryptographically secure random''' integer <math>k</math> from <math>[1, n-1]</math>.
# Calculate the curve point <math>(x_1, y_1) = k \times G</math>.
# Calculate <math>r = x_1\,\bmod\,n</math>. If <math>r = 0</math>, go back to step 3.
# Calculate <math>s = k^{-1}(z + r d_A)\,\bmod\,n</math>. If <math>s = 0</math>, go back to step 3.
# The signature is the pair <math>(r, s)</math>. (And <math>(r,-s\,\bmod\,n)</math> is also a valid signature.)

As the standard notes, it is not only required for <math>k</math> to be secret, but it is also crucial to select different <math>k</math> for different signatures. Otherwise, the equation in step 6 can be solved for <math>d_A</math>, the private key: given two signatures <math>(r, s)</math> and <math>(r, s')</math>, employing the same unknown <math>k</math> for different known messages <math>m</math> and <math>m'</math>, an attacker can calculate <math>z</math> and <math>z'</math>, and since <math>s - s' = k^{-1}(z - z')</math> (all operations in this paragraph are done modulo <math>n</math>) the attacker can find <math>k = \frac{z - z'}{s - s'}</math>. Since <math>s = k^{-1}(z + r d_A)</math>, the attacker can now calculate the private key <math>d_A = \frac{s k - z}{r}</math>.

This implementation failure was used, for example, to extract the signing key used for the [[PlayStation 3]] gaming-console.<ref>[https://events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf Console Hacking 2010 - PS3 Epic Fail] {{Webarchive|url=https://web.archive.org/web/20141215140847/http://events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf |date=December 15, 2014 }}, page 123–128</ref>

Another way ECDSA signature may leak private keys is when <math>k</math> is generated by a faulty [[random number generator]]. Such a failure in random number generation caused users of Android Bitcoin Wallet to lose their funds in August 2013.<ref>{{cite web|url=https://bitcoin.org/en/alert/2013-08-11-android|title=Android Security Vulnerability|access-date=February 24, 2015}}</ref>

To ensure that <math>k</math> is unique for each message, one may bypass random number generation completely and generate deterministic signatures by deriving <math>k</math> from both the message and the private key.<ref>{{cite tech report|url=https://www.rfc-editor.org/rfc/rfc6979.html|title=RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)|year=2013 |doi=10.17487/RFC6979 |access-date=February 24, 2015|last1=Pornin |first1=T. |doi-access=free }}</ref>

==Signature verification algorithm==
For Bob to authenticate Alice's signature <math>r, s</math> on a message <math>m</math>, he must have a copy of her public-key curve point <math>Q_A</math>. Bob can verify <math>Q_A</math> is a valid curve point as follows:

# Check that <math>Q_A</math> is not equal to the identity element {{mvar|O}}, and its coordinates are otherwise valid.
# Check that <math>Q_A</math> lies on the curve.
# Check that <math>n \times Q_A = O</math>.

After that, Bob follows these steps:

# Verify that {{mvar|r}} and {{mvar|s}} are integers in <math>[1, n-1]</math>. If not, the signature is invalid.
# Calculate <math>e = \textrm{HASH}(m)</math>, where HASH is the same function used in the signature generation.
# Let <math>z</math> be the <math>L_n</math> leftmost bits of {{mvar|e}}.
# Calculate <math>u_1 = zs^{-1}\,\bmod\,n</math> and <math>u_2 = rs^{-1}\,\bmod\,n</math>.
# Calculate the curve point <math>(x_1, y_1) = u_1 \times G + u_2 \times Q_A</math>. If <math>(x_1, y_1) = O</math> then the signature is invalid.
# The signature is valid if <math>r \equiv x_1 \pmod{n}</math>, invalid otherwise.

Note that an efficient implementation would compute inverse <math>s^{-1}\,\bmod\,n</math> only once. Also, using Shamir's trick, a sum of two scalar multiplications <math>u_1 \times G + u_2 \times Q_A</math> can be calculated faster than two scalar multiplications done independently.<ref>{{cite web | url=http://www.lirmm.fr/~imbert/talks/laurent_Asilomar_08.pdf | title=The Double-Base Number System in Elliptic Curve Cryptography | access-date=22 April 2014}}</ref>

===Correctness of the algorithm===
It is not immediately obvious why verification even functions correctly. To see why, denote as {{mvar|C}} the curve point computed in step 5 of verification,

: <math>C = u_1 \times G + u_2 \times Q_A</math>

From the definition of the public key as <math>Q_A = d_A \times G</math>,

: <math>C = u_1 \times G + u_2 d_A \times G</math>

Because elliptic curve scalar multiplication distributes over addition,

: <math>C = (u_1 + u_2 d_A) \times G</math>

Expanding the definition of <math>u_1</math> and <math>u_2</math> from verification step 4,

: <math>C = (z s^{-1} + r d_A s^{-1}) \times G</math>

Collecting the common term <math>s^{-1}</math>,

: <math>C = (z + r d_A) s^{-1} \times G</math>

Expanding the definition of {{mvar|s}} from signature step 6,

: <math>C = (z + r d_A) (z + r d_A)^{-1} (k^{-1})^{-1} \times G</math>

Since the inverse of an inverse is the original element, and the product of an element's inverse and the element is the identity, we are left with

: <math>C = k \times G</math>

From the definition of {{mvar|r}}, this is verification step 6.

This shows only that a correctly signed message will verify correctly; other properties such as incorrectly signed messages failing to verify correctly and resistance to [[Cryptanalysis|cryptanalytic]] attacks are required for a secure signature algorithm.

==Public key recovery==
Given a message {{mvar|m}} and Alice's signature <math>r, s</math> on that message, Bob can (potentially) recover Alice's public key:<ref>Daniel R. L. Brown [[SECG]] SEC 1: Elliptic Curve Cryptography (Version 2.0) https://www.secg.org/sec1-v2.pdf</ref>

# Verify that {{mvar|r}} and {{mvar|s}} are integers in <math>[1, n-1]</math>. If not, the signature is invalid.
# Calculate a curve point <math>R = (x_1, y_1)</math> where <math>x_1</math> is one of <math>r</math>, <math>r+n</math>, <math>r+2n</math>, etc. (provided <math>x_1</math> is not too large for the [[Field_(mathematics)|field]] of the curve) and <math>y_1</math> is a value such that the curve equation is satisfied. Note that there may be several curve points satisfying these conditions, and each different {{mvar|R}} value results in a distinct recovered key.
# Calculate <math>e = \textrm{HASH}(m)</math>, where HASH is the same function used in the signature generation.
# Let {{mvar|z}} be the <math>L_n</math> leftmost bits of {{mvar|e}}.
# Calculate <math>u_1 = -zr^{-1}\,\bmod\,n</math> and <math>u_2 = sr^{-1}\,\bmod\,n</math>.
# Calculate the curve point <math>Q_A = (x_A, y_A) = u_1 \times G + u_2 \times R</math>.
# The signature is valid if <math>Q_A</math>, matches Alice's public key.
# The signature is invalid if all the possible {{mvar|R}} points have been tried and none match Alice's public key.

Note that an invalid signature, or a signature from a different message, will result in the recovery of an incorrect public key. The recovery algorithm can only be used to check validity of a signature if the signer's public key (or its hash) is known beforehand.

===Correctness of the recovery algorithm===
Start with the definition of <math>Q_A</math> from recovery step 6,

: <math>Q_A = (x_A, y_A) = u_1 \times G + u_2 \times R</math>

From the definition <math>R = (x_1, y_1) = k \times G</math> from signing step 4,

: <math>Q_A = u_1 \times G + u_2 k \times G</math>

Because elliptic curve scalar multiplication distributes over addition,

: <math>Q_A = (u_1 + u_2 k) \times G</math>

Expanding the definition of <math>u_1</math> and <math>u_2</math> from recovery step 5,

: <math>Q_A = (-z r^{-1} + s k r^{-1}) \times G</math>

Expanding the definition of {{mvar|s}} from signature step 6,

: <math>Q_A = (-z r^{-1} + k^{-1} (z + r d_A) k r^{-1}) \times G</math>

Since the product of an element's inverse and the element is the identity, we are left with

: <math>Q_A = (-z r^{-1} + (z r^{-1} + d_A)) \times G</math>

The first and second terms cancel each other out,

: <math>Q_A = d_A \times G</math>

From the definition of <math>Q_A = d_A \times G</math>, this is Alice's public key.

This shows that a correctly signed message will recover the correct public key, provided additional information was shared to uniquely calculate curve point <math>R = (x_1, y_1)</math> from signature value {{mvar|r}}.

==Security==
In December 2010, a group calling itself ''fail0verflow'' announced the recovery of the ECDSA private key used by [[Sony]] to sign software for the [[PlayStation 3]] game console. However, this attack only worked because Sony did not properly implement the algorithm, because <math>k</math> was static instead of random. As pointed out in the [[#Signature generation algorithm|Signature generation algorithm]] section above, this makes <math>d_A</math> solvable, rendering the entire algorithm useless.<ref>{{Cite news|last=Bendel|first=Mike|title=Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access|publisher=Exophase.com|date=2010-12-29|url=http://exophase.com/20540/hackers-describe-ps3-security-as-epic-fail-gain-unrestricted-access/|access-date=2011-01-05}}</ref>

On March 29, 2011, two researchers published an [[International Association for Cryptologic Research|IACR]] paper<ref>{{cite web|url=http://eprint.iacr.org/2011/232|title=Cryptology ePrint Archive: Report 2011/232|access-date=February 24, 2015}}</ref> demonstrating that it is possible to retrieve a TLS private key of a server using [[OpenSSL]] that authenticates with Elliptic Curves DSA over a binary [[Field (mathematics)|field]] via a [[timing attack]].<ref>{{cite web|url=https://www.kb.cert.org/vuls/id/536044|title=Vulnerability Note VU#536044 - OpenSSL leaks ECDSA private key through a remote timing attack|website=www.kb.cert.org}}</ref> The vulnerability was fixed in OpenSSL 1.0.0e.<ref>{{cite web | url=http://www.openssl.org/news/changelog.html | title=ChangeLog | publisher=OpenSSL Project | access-date=22 April 2014}}</ref>

In August 2013, it was revealed that bugs in some implementations of the [[Java (programming language)|Java]] class [https://docs.oracle.com/javase/10/docs/api/java/security/SecureRandom.html SecureRandom] sometimes generated collisions in the <math>k</math> value. This allowed hackers to recover private keys giving them the same control over bitcoin transactions as legitimate keys' owners had, using the same exploit that was used to reveal the PS3 signing key on some [[Android (operating system)|Android]] app implementations, which use Java and rely on ECDSA to authenticate transactions.<ref>{{cite web |title=Android bug batters Bitcoin wallets
| url= https://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets/ |publisher=The Register |date=12 August 2013}}</ref>

This issue can be prevented by deterministic generation of k, as described by RFC 6979.

=== Concerns ===
Some concerns expressed about ECDSA:

# ''Political concerns'': the trustworthiness of [[National Institute of Standards and Technology|NIST]]-produced curves being questioned after revelations were made that the [[National Security Agency|NSA]] willingly inserts [[Backdoor (computing)|backdoors]] into software, hardware components and published standards; well-known cryptographers<ref>{{cite web|url=https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929|title=The NSA Is Breaking Most Encryption on the Internet|website=Schneier on Security|first=Bruce|last=Schneier|date=September 5, 2013}}</ref> have expressed<ref>{{cite web|url=http://safecurves.cr.yp.to/rigid.html|title=SafeCurves: choosing safe curves for elliptic-curve cryptography|date=Oct 25, 2013}}</ref><ref>{{cite web|url=https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf|title=Security dangers of the NIST curves|first1=Daniel J.|last1=Bernstein|first2=Tanja|last2=Lange|author2-link=Tanja Lange|date=May 31, 2013}}</ref> doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past.<ref>{{cite web|url=https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html|title=The Strange Story of Dual_EC_DRBG|website=Schneier on Security|first=Bruce|last=Schneier|date=November 15, 2007}}</ref><ref>{{cite web|url=http://www.scientificamerican.com/article/nsa-nist-encryption-scandal/|title=NSA Efforts to Evade Encryption Technology Damaged U.S. Cryptography Standard|first=Larry|last=Greenemeier|publisher=Scientific American|date=September 18, 2013}}</ref> (See also the ''libssh [[curve25519]] introduction''.<ref>{{cite web|url=https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4|title=curve25519-sha256@libssh.org.txt\doc - projects/libssh.git|website=libssh shared repository}}</ref>) Nevertheless, a proof that the named NIST curves exploit a rare weakness is still missing.
# ''Technical concerns'': the difficulty of properly implementing the standard, its slowness, and design flaws which reduce security in insufficiently defensive implementations.<ref>{{cite web|url=http://blog.cr.yp.to/20140323-ecdsa.html|title=How to design an elliptic-curve signature system|first=Daniel J.|last=Bernstein|date=March 23, 2014|website=The cr.yp.to blog}}</ref>

== Implementations ==
Below is a list of cryptographic libraries that provide support for ECDSA:

* [[Botan (programming library)|Botan]]
* [[Bouncy Castle (cryptography)|Bouncy Castle]]
* [[cryptlib]]
* [[Crypto++]]
* [[Crypto API (Linux)]]
* [[GnuTLS]]
* [[libgcrypt]]
* [[LibreSSL]]
* [[mbed TLS]]
* [[Microsoft CryptoAPI]]
* [[OpenSSL]]
* [[wolfCrypt]]

==See also==
* [[EdDSA]]
* [[RSA (cryptosystem)]]

==References==
{{Reflist|30em}}

==Further reading==
* Accredited Standards Committee [http://www.x9.org X9], ''ASC X9 Issues New Standard for Public Key Cryptography/ECDSA'', Oct. 6, 2020. [https://x9.org/asc-x9-issues-new-standard-for-public-key-cryptography-ecdsa/ Source]
* Accredited Standards Committee [http://www.x9.org X9], ''American National Standard X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)'', November 16, 2005.
* Certicom Research, [https://www.secg.org/sec1-v2.pdf ''Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography''], Version 2.0, May 21, 2009.
* López, J. and Dahab, R. [http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.2771 ''An Overview of Elliptic Curve Cryptography''], Technical Report IC-00-10, State University of Campinas, 2000.
* [[Daniel J. Bernstein]], [http://cr.yp.to/papers/pippenger.pdf Pippenger's exponentiation algorithm], 2002.
* Daniel R. L. Brown, ''Generic Groups, Collision Resistance, and ECDSA'', Designs, Codes and Cryptography, '''35''', 119–152, 2005. [http://eprint.iacr.org/2002/026 ePrint version]
* Ian F. Blake, Gadiel Seroussi, and [[Nigel_Smart_(cryptographer)|Nigel Smart]], editors, ''Advances in Elliptic Curve Cryptography'', London Mathematical Society Lecture Note Series 317, Cambridge University Press, 2005.
* {{Cite book | last1 = Hankerson | first1 = D. | last2 = Vanstone | first2 = S. | author-link2 = Scott Vanstone | last3 = Menezes | first3 = A. | author-link3 = Alfred Menezes | doi = 10.1007/b97644 | title = Guide to Elliptic Curve Cryptography | series = Springer Professional Computing | publisher = [[Springer Science+Business Media|Springer]]| location = New York| year = 2004 | isbn = 0-387-95273-X | s2cid = 720546 }}

==External links==
* [https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf Digital Signature Standard; includes info on ECDSA]
* [https://web.archive.org/web/20160304101319/http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf The Elliptic Curve Digital Signature Algorithm (ECDSA); provides an in-depth guide on ECDSA]. [https://web.archive.org/web/20100627011540/http://cs.ucsb.edu/~koc/ccs130h/notes/ecdsa-cert.pdf Wayback link]

{{Cryptography navbox|public-key}}

{{Bitcoin}}

{{DEFAULTSORT:Elliptic Curve Dsa}}
[[Category:Public-key cryptography]]
[[Category:Elliptic curve cryptography]]
[[Category:Digital signature schemes]]
[[Category:Digital Signature Standard]]