Elliptic Curve Digital Signature Algorithm

As with elliptic-curve cryptography in general, the bit size of the public key believed to be needed for ECDSA is about twice the size of the security level, in bits. For example, at a security level of 80 bits (meaning an attacker requires a maximum of about ${\displaystyle 2^{80}}$ operations to find the private key) the size of an ECDSA private key would be 160 bits, whereas the size of a DSA private key is at least 1024 bits. On the other hand, the signature size is the same for both DSA and ECDSA: approximately ${\displaystyle 4t}$ bits, where ${\displaystyle t}$ is the security level measured in bits, that is, about 320 bits for a security level of 80 bits.

Suppose Alice wants to send a signed message to Bob. Initially, they must agree on the curve parameters ${\displaystyle ({\textrm {CURVE}},G,n)}$. In addition to the field and equation of the curve, we need ${\displaystyle G}$, a base point of prime order on the curve; ${\displaystyle n}$ is the multiplicative order of the point ${\displaystyle G}$.

Parameter
CURVE	the elliptic curve field and equation used
G	elliptic curve base point, a point on the curve that generates a subgroup of large prime order n
n	integer order of G, means that ${\displaystyle n\times G=O}$, where ${\displaystyle O}$ is the identity element.
${\displaystyle d_{A}}$	the private key (randomly selected)
${\displaystyle Q_{A}}$	the public key (calculated by elliptic curve)
m	the message to send

The order ${\displaystyle n}$ of the base point ${\displaystyle G}$ must be prime. Indeed, we assume that every nonzero element of the ring ${\displaystyle \mathbb {Z} /n\mathbb {Z} }$ is invertible, so that ${\displaystyle \mathbb {Z} /n\mathbb {Z} }$ must be a field. It implies that ${\displaystyle n}$ must be prime (cf. Bézout's identity).

Alice creates a key pair, consisting of a private key integer ${\displaystyle d_{A}}$, randomly selected in the interval ${\displaystyle [1,n-1]}$; and a public key curve point ${\displaystyle Q_{A}=d_{A}\times G}$. We use ${\displaystyle \times }$ to denote elliptic curve point multiplication by a scalar.

For Alice to sign a message ${\displaystyle m}$, she follows these steps:

1. Calculate ${\displaystyle e={\textrm {HASH}}(m)}$. (Here HASH is a cryptographic hash function, such as SHA-2, with the output converted to an integer.)
2. Let ${\displaystyle z}$ be the ${\displaystyle L_{n}}$ leftmost bits of ${\displaystyle e}$, where ${\displaystyle L_{n}}$ is the bit length of the group order ${\displaystyle n}$. (Note that ${\displaystyle z}$ can be greater than ${\displaystyle n}$ but not longer.[1])
3. Select a cryptographically secure random integer ${\displaystyle k}$ from ${\displaystyle [1,n-1]}$.
4. Calculate the curve point ${\displaystyle (x_{1},y_{1})=k\times G}$.
5. Calculate ${\displaystyle r=x_{1}\,{\bmod {\,}}n}$. If ${\displaystyle r=0}$, go back to step 3.
6. Calculate ${\displaystyle s=k^{-1}(z+rd_{A})\,{\bmod {\,}}n}$. If ${\displaystyle s=0}$, go back to step 3.
7. The signature is the pair ${\displaystyle (r,s)}$. (And ${\displaystyle (r,-s\,{\bmod {\,}}n)}$ is also a valid signature.)

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

This implementation failure was used, for example, to extract the signing key used for the PlayStation 3 gaming-console.[2]

Another way ECDSA signature may leak private keys is when ${\displaystyle k}$ 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.[3]

To ensure that ${\displaystyle k}$ is unique for each message, one may bypass random number generation completely and generate deterministic signatures by deriving ${\displaystyle k}$ from both the message and the private key.[4]

For Bob to authenticate Alice's signature, he must have a copy of her public-key curve point ${\displaystyle Q_{A}}$. Bob can verify ${\displaystyle Q_{A}}$ is a valid curve point as follows:

1. Check that ${\displaystyle Q_{A}}$ is not equal to the identity element O, and its coordinates are otherwise valid
2. Check that ${\displaystyle Q_{A}}$ lies on the curve
3. Check that ${\displaystyle n\times Q_{A}=O}$

After that, Bob follows these steps:

1. Verify that r and s are integers in ${\displaystyle [1,n-1]}$. If not, the signature is invalid.
2. Calculate ${\displaystyle e={\textrm {HASH}}(m)}$, where HASH is the same function used in the signature generation.
3. Let z be the ${\displaystyle L_{n}}$ leftmost bits of e.
4. Calculate ${\displaystyle u_{1}=zs^{-1}\,{\bmod {\,}}n}$ and ${\displaystyle u_{2}=rs^{-1}\,{\bmod {\,}}n}$.
5. Calculate the curve point ${\displaystyle (x_{1},y_{1})=u_{1}\times G+u_{2}\times Q_{A}}$. If ${\displaystyle (x_{1},y_{1})=O}$ then the signature is invalid.
6. The signature is valid if ${\displaystyle r\equiv x_{1}{\pmod {n}}}$, invalid otherwise.

Note that an efficient implementation would compute inverse ${\displaystyle s^{-1}\,{\bmod {\,}}n}$ only once. Also, using Shamir's trick, a sum of two scalar multiplications ${\displaystyle u_{1}\times G+u_{2}\times Q_{A}}$ can be calculated faster than two scalar multiplications done independently.[5]

Given a message m and Alice's signature ${\displaystyle r,s}$ on that message, Bob can (potentially) recover Alice's public key:[6]

1. Verify that r and s are integers in ${\displaystyle [1,n-1]}$. If not, the signature is invalid.
2. Calculate a curve point ${\displaystyle R=(x_{1},y_{1})}$ where ${\displaystyle x_{1}}$ is one of ${\displaystyle r}$, ${\displaystyle r+n}$, ${\displaystyle r+2n}$, etc. (provided ${\displaystyle x_{1}}$ is not too large for a field element) and ${\displaystyle y_{1}}$ is a value such that the curve equation is satisfied. Note that there may be several curve points satisfying these conditions, and each different R value results in a distinct recovered key.
3. Calculate ${\displaystyle e={\textrm {HASH}}(m)}$, where HASH is the same function used in the signature generation.
4. Let z be the ${\displaystyle L_{n}}$ leftmost bits of e.
5. Calculate ${\displaystyle u_{1}=-zr^{-1}\,{\bmod {\,}}n}$ and ${\displaystyle u_{2}=sr^{-1}\,{\bmod {\,}}n}$.
6. Calculate the curve point ${\displaystyle Q_{A}=(x_{A},y_{A})=u_{1}\times G+u_{2}\times R}$.
7. The signature is valid if ${\displaystyle Q_{A}}$, matches Alice's public key.
8. The signature is invalid if all the possible 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.

In December 2010, a group calling itself fail0verflow announced 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 ${\displaystyle k}$ was static instead of random. As pointed out in the Signature generation algorithm section above, this makes ${\displaystyle d_{A}}$ solvable, rendering the entire algorithm useless.[7]

On March 29, 2011, two researchers published an IACR paper[8] 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 via a timing attack.[9] The vulnerability was fixed in OpenSSL 1.0.0e.[10]

In August 2013, it was revealed that bugs in some implementations of the Java class SecureRandom sometimes generated collisions in the ${\displaystyle k}$ 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 app implementations, which use Java and rely on ECDSA to authenticate transactions.[11]

This issue can be prevented by an unpredictable generation of ${\displaystyle k}$, e.g., a deterministic procedure as described by RFC 6979.

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

• Botan
• Bouncy Castle
• cryptlib
• Crypto++
• libgcrypt
• GnuTLS
• OpenSSL
• wolfCrypt
• LibreSSL
• mbed TLS
• Microsoft CryptoAPI
• Crypto API (Linux)

Wikipedia.org uses ECDSA in a TLS ciphersuite to authenticate itself to web browsers, which the following abbreviated transcript shows.

$ date
Wed Mar  4 10:24:52 EST 2020
$ openssl s_client -connect wikipedia.org:443  # output below has DELETIONS for brevity
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.wikipedia.org
verify return:1
---
Certificate chain
 0 s:/CN=*.wikipedia.org
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHOTCCBiGgAwIBAgISA4srJU6bpT7xpINN6bbGO2/mMA0GCSqGSIb3DQEBCwUA
     ... many lines DELETED ....
kTOXMoKzBkJCU8sCdeziusJtNvWXW6p8Z3UpuTw=
-----END CERTIFICATE-----
subject=/CN=*.wikipedia.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3353 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID:  ... DELETED ...
    Session-ID-ctx: 
    Master-Key:     ... DELETED ...
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1583335210
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

• EdDSA
• RSA (cryptosystem)

• Accredited Standards Committee X9, ASC X9 Issues New Standard for Public Key Cryptography/ECDSA, Oct. 6, 2020. Source
• Accredited Standards Committee 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, Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography, Version 2.0, May 21, 2009.
• López, J. and Dahab, R. An Overview of Elliptic Curve Cryptography, Technical Report IC-00-10, State University of Campinas, 2000.
• Daniel J. Bernstein, Pippenger's exponentiation algorithm, 2002.
• Daniel R. L. Brown, Generic Groups, Collision Resistance, and ECDSA, Designs, Codes and Cryptography, 35, 119–152, 2005. ePrint version
• Ian F. Blake, Gadiel Seroussi, and Nigel Smart, editors, Advances in Elliptic Curve Cryptography, London Mathematical Society Lecture Note Series 317, Cambridge University Press, 2005.
• Hankerson, D.; Vanstone, S.; Menezes, A. (2004). Guide to Elliptic Curve Cryptography. Springer Professional Computing. New York: Springer. doi:10.1007/b97644. ISBN 0-387-95273-X. S2CID 720546.

• Digital Signature Standard; includes info on ECDSA
• The Elliptic Curve Digital Signature Algorithm (ECDSA); provides an in-depth guide on ECDSA. Wayback link