In cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic-curve cryptography.
As with elliptic-curve cryptography in general, the bit size of the private key believed to be needed for ECDSA is about twice the size of the security level, in bits. [1] For example, at a security level of 80 bits—meaning an attacker requires a maximum of about 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 bits, where is the exponent in the formula , that is, about 320 bits for a security level of 80 bits, which is equivalent to operations.
Suppose Alice wants to send a signed message to Bob. Initially, they must agree on the curve parameters . In addition to the field and equation of the curve, we need , a base point of prime order on the curve; is the multiplicative order of the point .
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 , where is the identity element. |
the private key (randomly selected) | |
the public key (calculated by elliptic curve) | |
m | the message to send |
The order of the base point must be prime. Indeed, we assume that every nonzero element of the ring is invertible, so that must be a field. It implies that must be prime (cf. Bézout's identity).
Alice creates a key pair, consisting of a private key integer , randomly selected in the interval ; and a public key curve point . We use to denote elliptic curve point multiplication by a scalar.
For Alice to sign a message , she follows these steps:
As the standard notes, it is not only required for to be secret, but it is also crucial to select different for different signatures. Otherwise, the equation in step 6 can be solved for , the private key: given two signatures and , employing the same unknown for different known messages and , an attacker can calculate and , and since (all operations in this paragraph are done modulo ) the attacker can find . Since , the attacker can now calculate the private key .
This implementation failure was used, for example, to extract the signing key used for the PlayStation 3 gaming-console. [3]
Another way ECDSA signature may leak private keys is when 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. [4]
To ensure that is unique for each message, one may bypass random number generation completely and generate deterministic signatures by deriving from both the message and the private key. [5]
For Bob to authenticate Alice's signature on a message , he must have a copy of her public-key curve point . Bob can verify is a valid curve point as follows:
After that, Bob follows these steps:
Note that an efficient implementation would compute inverse only once. Also, using Shamir's trick, a sum of two scalar multiplications can be calculated faster than two scalar multiplications done independently. [6]
It is not immediately obvious why verification even functions correctly. To see why, denote as C the curve point computed in step 5 of verification,
From the definition of the public key as ,
Because elliptic curve scalar multiplication distributes over addition,
Expanding the definition of and from verification step 4,
Collecting the common term ,
Expanding the definition of s from signature step 6,
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
From the definition of 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 cryptanalytic attacks are required for a secure signature algorithm.
Given a message m and Alice's signature on that message, Bob can (potentially) recover Alice's public key: [7]
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.
Start with the definition of from recovery step 6,
From the definition from signing step 4,
Because elliptic curve scalar multiplication distributes over addition,
Expanding the definition of and from recovery step 5,
Expanding the definition of s from signature step 6,
Since the product of an element's inverse and the element is the identity, we are left with
The first and second terms cancel each other out,
From the definition of , 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 from signature value r.
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 was static instead of random. As pointed out in the Signature generation algorithm section above, this makes solvable, rendering the entire algorithm useless. [8]
On March 29, 2011, two researchers published an IACR paper [9] 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. [10] The vulnerability was fixed in OpenSSL 1.0.0e. [11]
In August 2013, it was revealed that bugs in some implementations of the Java class SecureRandom sometimes generated collisions in the 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. [12]
This issue can be prevented by deterministic generation of k, as described by RFC 6979.
Some concerns expressed about ECDSA:
Below is a list of cryptographic libraries that provide support for ECDSA: