The **ECDSA** (Elliptic Curve Digital Signature Algorithm) is a cryptographically secure **digital signature scheme**, based on the elliptic-curve cryptography (**ECC**). **ECDSA** relies on the math of the **cyclic groups of elliptic curves over finite fields** and on the difficulty of the **ECDLP problem** (elliptic-curve discrete logarithm problem). The **ECDSA sign / verify** algorithm relies on EC point multiplication and works as described below. ECDSA keys and signatures are shorter than in RSA for the same security level. A 256-bit ECDSA signature has the same security strength like 3072-bit RSA signature.

**ECDSA** uses cryptographic **elliptic curves** (EC) over finite fields in the classical Weierstrass form. These curves are described by their **EC domain parameters**, specified by various cryptographic standards such as **SECG: SEC 2** and **Brainpool (RFC 5639)**. Elliptic curves, used in cryptography, define:

**Generator point****G**, used for scalar multiplication on the curve (multiply integer by EC point)**Order**of the subgroup of EC points, generated by*n***G**, which defines the length of the private keys (e.g. 256 bits)

For example, the 256-bit elliptic curve `secp256k1`

has:

Order

= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (prime number)*n*Generator point

**G**{= 55066263022277343669578718895168534326250603453777594175500187360389116729240,*x*= 32670510020758816978083085130507043184471273380659243275938904335757337482424}*y*

The **ECDSA key-pair** consists of:

**private key**(integer):*privKey***public key**(EC point):=*pubKey***privKey***G**

The **private key** is generated as a **random integer** in the range [0...** n**-1]. The public key

The public key EC point {** x**,

`secp256k1`

curve, the private key is 256-bit integer (32 bytes) and the compressed public key is 257-bit integer (~ 33 bytes).The ECDSA signing algorithm (**RFC 6979**) takes as input a message *msg*** **+ a private key *privKey*** **and produces as output a **signature**, which consists of pair of integers {** r**,

Calculate the message

**hash**, using a cryptographic hash function like SHA-256:= hash(*h*)*msg*Generate securely a

**random**numberin the range [1..*k*-1]*n*In case of

**deterministic-ECDSA**, the valueis HMAC-derived from*k*+*h*(see RFC 6979)*privKey*

Calculate the random point

=*R***k***G**and take its x-coordinate:=*r**R***.x**Calculate the signature proof:

= $k^{-1} * (h + r * privKey) \pmod n$*s*The modular inverse $k^{-1} \pmod n$ is an integer, such that $k * k^{-1} \equiv 1 \pmod n$

Return the

**signature**{,*r*}.*s*

The calculated **signature** {** r**,

**ECDSA signatures** are **2 times longer** than the signer's **private key** for the curve used during the signing process. For example, for 256-bit elliptic curves (like `secp256k1`

) the ECDSA signature is 512 bits (64 bytes) and for 521-bit curves (like `secp521r1`

) the signature is 1042 bits.

The algorithm to **verify a ECDSA signature** takes as input the signed message ** msg** + the signature {

Calculate the message

**hash**, with the same cryptographic hash function used during the signing:= hash(*h*)*msg*Calculate the modular inverse of the signature proof:

= $s^{-1} \pmod n$*s1*Recover the random point used during the signing:

= (*R'***h***s1**) ***G**+ (**r*) **s1**pubKey*Take from

its x-coordinate:*R'*=*r'**R'***.x**Calculate the signature validation

**result**by comparing whether==*r'**r*

The general idea of the signature verification is to **recover the point **** R'** using the public key and check whether it is same point

The **ECDSA signature** {** r**,

The signing

**signing**encodes a random point(represented by its x-coordinate only) through elliptic-curve transformations using the private key*R*and the message hash*privKey*into a number*h*, which is the*s***proof**that the message signer knows the private key. The signature {*privKey*,*r*} cannot reveal the private key due to the difficulty of the*s***ECDLP problem**.The

**signature verification**decodes the proof numberfrom the signature back to its original point*s*, using the public key*R*and the message hash*pubKey*and compares the x-coordinate of the recovered*h*with the*R*value from the signature.*r*

Read this section **only if you like math**. Most developer may skip it.

How does the above sign / verify scheme work? It is not obvious, but let's play a bit with the equations.

The equation behind the recovering of the point ** R'**, calculated during the

** R'** = (

If we take the number ** s** = $k^{-1} * (h + r * privKey) \pmod n$

** s1** = $s^{-1} \pmod n$ =
= $(k^{-1} * (h + r * privKey))^{-1} \pmod n$ =
= $k * (h + r * privKey)^{-1} \pmod n$

Now, replace ** s1** in the point

** R'** = (

The final step is to **compare** the **point **** R'** (decoded by the

It is expected that ** r'** ==

It is important to know that the **ECDSA signature scheme** allows the **public key to be recovered** from the signed **message** together with the **signature**. The recovery process is based on some **mathematical computations** (described in the **SECG: SEC 1** standard) and returns 0, 1 or 2 possible EC points that are valid **public keys**, corresponding to the signature. To avoid this ambiguity, some ECDSA implementations add one additional bit ** v** to the signature during the signing process and it takes the form {

The **public key recovery from the ECDSA signature** is very useful in bandwidth constrained or storage constrained environments (such as blockchain systems), when transmission or storage of the public keys cannot be afforded. For example, the Ethereum blockchain uses extended signatures {** r**,

Public key recovery is possible for signatures, based on the **ElGamal signature scheme** (such as DSA and ECDSA).