Elliptic Curve Digital Signature Algorithm

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-sizeEdit

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   operations to find the private key) the size of an ECDSA public key would be 160 bits, whereas the size of a DSA public key is at least 1024 bits. On the other hand, the signature size is the same for both DSA and ECDSA: approximately   bits, where   is the security level measured in bits, that is, about 320 bits for a security level of 80 bits.

Signature generation algorithmEdit

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:

  1. Calculate  . (Here HASH is a cryptographic hash function, such as SHA-2, with the output converted to an integer.)
  2. Let   be the   leftmost bits of  , where   is the bit length of the group order  . (Note that   can be greater than   but not longer.[1])
  3. Select a cryptographically secure random integer   from  .
  4. Calculate the curve point  .
  5. Calculate  . If  , go back to step 3.
  6. Calculate  . If  , go back to step 3.
  7. The signature is the pair  . (And   is also a valid signature.)


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.[2]

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.[3]

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.[4]

Signature verification algorithmEdit

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

  1. Check that   is not equal to the identity element  , and its coordinates are otherwise valid
  2. Check that   lies on the curve
  3. Check that  

After that, Bob follows these steps:

  1. Verify that   and   are integers in  . If not, the signature is invalid.
  2. Calculate  , where HASH is the same function used in the signature generation.
  3. Let   be the   leftmost bits of  .
  4. Calculate   and  .
  5. Calculate the curve point  . If   then the signature is invalid.
  6. The signature is valid if  , invalid otherwise.

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.[5]

Correctness of the algorithmEdit

It is not immediately obvious why verification even functions correctly. To see why, denote as   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   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  , this is verification step 6.

This shows only that a correctly signed message will verify correctly; many other properties[which?] are required for a secure signature algorithm.

Public key recoveryEdit

Given a message   and Alice's signature   on that message, Bob can (potentially) recover Alice's public key:[6]

  1. Verify that   and   are integers in  . If not, the signature is invalid.
  2. Calculate a curve point   where   is one of  ,  ,  , etc. (provided   is not too large for a field element) and   is a value such that the curve equation is satisfied. Note that there may be several curve points satisfying these conditions, and each different   value results in a distinct recovered key.
  3. Calculate  , where HASH is the same function used in the signature generation.
  4. Let   be the   leftmost bits of  .
  5. Calculate   and  .
  6. Calculate the curve point  .
  7. The signature is valid if  , matches Alice's public key.
  8. The signature is invalid if all the possible   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 algorithmEdit

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   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  .

SecurityEdit

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   was static instead of random. As pointed out in the Signature generation algorithm section above, this makes   solvable and 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   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 unpredictible generation of  , e.g., a deterministic procedure as described by RFC 6979.

ConcernsEdit

There exist two sorts of concerns with ECDSA:

  1. Political concerns: the trustworthiness of NIST-produced curves being questioned after revelations that the NSA willingly inserts backdoors into software, hardware components and published standards were made; well-known cryptographers[12] have expressed[13][14] doubts about how the NIST curves were designed, and voluntary tainting has already been proved in the past.[15][16]. Nevertheless, a proof, that the named NIST curves exploit a rare weakness, is missing yet.
  2. Technical concerns: the difficulty of properly implementing the standard,[17] its slowness, and design flaws which reduce security in insufficiently defensive implementations of the Dual_EC_DRBG random number generator.[18]

Both of those concerns are summarized in libssh curve25519 introduction.[19]

ImplementationsEdit

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

Example usageEdit

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

See alsoEdit

ReferencesEdit

  1. ^ NIST FIPS 186-4, July 2013, pp. 19 and 26
  2. ^ Console Hacking 2010 - PS3 Epic Fail Archived December 15, 2014, at the Wayback Machine, page 123–128
  3. ^ "Android Security Vulnerability". Retrieved February 24, 2015.
  4. ^ "RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)". Retrieved February 24, 2015.
  5. ^ "The Double-Base Number System in Elliptic Curve Cryptography" (PDF). Retrieved April 22, 2014.
  6. ^ Daniel R. L. Brown SECG SEC 1: Elliptic Curve Cryptography (Version 2.0) https://www.secg.org/sec1-v2.pdf
  7. ^ Bendel, Mike (December 29, 2010). "Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access". Exophase.com. Retrieved January 5, 2011.
  8. ^ "Cryptology ePrint Archive: Report 2011/232". Retrieved February 24, 2015.
  9. ^ "Vulnerability Note VU#536044 - OpenSSL leaks ECDSA private key through a remote timing attack". www.kb.cert.org.
  10. ^ "ChangeLog". OpenSSL Project. Retrieved April 22, 2014.
  11. ^ "Android bug batters Bitcoin wallets". The Register. August 12, 2013.
  12. ^ Schneier, Bruce (September 5, 2013). "The NSA Is Breaking Most Encryption on the Internet". Schneier on Security.
  13. ^ "SafeCurves: choosing safe curves for elliptic-curve cryptography". October 25, 2013.
  14. ^ Bernstein, Daniel J.; Lange, Tanja (May 31, 2013). "Security dangers of the NIST curves" (PDF).
  15. ^ Schneier, Bruce (November 15, 2007). "The Strange Story of Dual_EC_DRBG". Schneier on Security.
  16. ^ Greenemeier, Larry (September 18, 2013). "NSA Efforts to Evade Encryption Technology Damaged U.S. Cryptography Standard". Scientific American.
  17. ^ Bernstein, Daniel J. (March 23, 2014). "How to design an elliptic-curve signature system". The cr.yp.to blog.
  18. ^ "New key type (ed25519) and private key format".
  19. ^ "curve25519-sha256@libssh.org.txt\doc - projects/libssh.git". libssh shared repository.

Further readingEdit

External linksEdit