When we talk about Ethereum or blockchain in general, trust is one thing that resonates with us.

A part of that trust comes from using digital signatures.

Ethereum uses Elliptic Curve Digital Signature Algorithm or  ECDSA as its signature scheme.

Whenever you are signing your transaction, the underlying digital signature scheme uses ECDSA.

In this blog, we are going to talk about how Ethereum uses this fascinating technology.

What are Digital Signatures?

A digital signature is a cryptographic technique used to verify the authenticity and integrity of digital documents or messages.

 It provides a means for proving that a specific message or document was sent by a particular entity and has not been tampered with during transmission. 

Digital signatures are a crucial aspect of modern cybersecurity, ensuring secure communication and data integrity in various applications, including secure messaging, software distribution, online transactions, and more.

How Digital Signatures Work

Cryptography is divided into two main categories: Symmetric Key Cryptography and Asymmetric Key Cryptography.

Symmetric Key Cryptography uses a single key for both encryption and decryption. 

To decipher the information, one needs the exact key used for encryption.

Asymmetric Key Cryptography, on the other hand, involves the generation of a key pair for both the sender and receiver. 

The public key is accessible to everyone, while the private key is known only to its owner.

 When the sender wants to send data securely to the receiver, they encrypt it using the receiver’s public key, and then the receiver can decrypt it using their private key. 

One example of Asymmetric Key Cryptography is ECDSA, which stands for Elliptic Curve Digital Signature Algorithm.

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic curve

analogue of the Digital Signature Algorithm (DSA). It was accepted in 1999

as an ANSI standard, and was accepted in 2000 as IEEE and NIST

standards. It was also accepted in 1998 as an ISO standard, and is under

consideration for inclusion in some other ISO standards.

Before Bitcoin adopted ECDSA, this cryptographic algorithm was not widely known. One of the main factors contributing to its popularity in the blockchain space is its cost-effectiveness and the relatively short length of keys it uses.

An Elliptic Curve is defined by the equation 

y² = x³ + ax + b

Working of ECDSA and Signing

ECDSA uses an elliptic curve. It looks like this –

 There are many types of Elliptic Curves. One of them which Ethereum uses is secp256k1.

The secp256k1 elliptic curve serves as the foundation for cryptographic operations due to its prime order finite field properties. 

Its selection is based on its ability to provide robust security while enabling efficient computation for essential tasks like key generation, signature generation, and signature verification.

Within Ethereum, the secp256k1 signature scheme is widely employed to sign transactions, messages, and data. This process entails utilizing a private key to create a digital signature, while the associated public key is used for signature verification.

1. The process of signing a message using ECDSA (Elliptic Curve Digital Signature Algorithm) involves a user utilizing their private key and a cryptographic algorithm to generate a unique digital signature. This signature consists of two components: ‘r’ and ‘s’, which are derived from the signing process.

2. To sign a transaction, the user first hashes the transaction data and then uses their private key to create the signature. The ‘r’ value represents a point on the elliptic curve and plays a part in the signature, while the ‘s’ value is a scalar value that forms the other part of the signature. Together, ‘r’ and ‘s’ form the digital signature of the transaction.

3. When a transaction is sent to the Ethereum network, nodes receiving it can independently verify its authenticity and integrity. 

The verification process involves using the sender’s public key, the digital signature (r and s), and the transaction data.

4. In Ethereum, the public key can be recovered from the digital signature (r and s). This means that the recipient or network nodes can determine the sender’s address without explicitly being provided with the public key.

 The recovery process involves extracting the sender’s public key from the signature through mathematical operations.

5. During signature verification, the ‘r’ and ‘s’ values are used along with the sender’s recovered public key to validate the authenticity of the signature.

The verification process ensures that the signature matches the transaction data and that it was created using the private key corresponding to the sender’s public key. This way, the integrity and validity of the transaction can be confirmed.

But why can’t we use hashing to check the integrity?

One common question that gets asked is that if the purpose of hashing is also to check the data integrity, then why can’t we use hashing to check if the transaction is valid or not? 

The answer is that although – 

Hashing can ensure data integrity, but it does not provide a means to verify the data’s origin.

Signing of Transaction

Since we have covered the basics of digital signatures before, here is how Ethereum uses ECDSA for signing transactions.

According to the Yellow Paper  – 

1. ECDSA signatures utilize SECP-256k1 curve
2. It is assumed that the user has a private key {p_r}. This key is a randomly selected positive integer which will be represented as an array length of 32 in big endian format .
3. The range of private key is [1, secp256k1n − 1]

What is big endian Format

When we talk about storing a 32-bit pattern in memory, it means we need to store a sequence of 32 binary digits (0s and 1s) in a computer’s memory. However, the question is, how do we arrange these bits within the memory?

There are two common ways computers handle this arrangement: big endian and little endian.

1. Big Endian Byte Order: In big-endian byte order, the most significant byte of the 32-bit pattern is stored at the lowest address in memory. The remaining bytes are stored in ascending order of significance. So, if we have the pattern 0x12345678, the most significant byte (0x12) would be stored at the lowest memory address, followed by 0x34, 0x56, and finally 0x78.
2. Little Endian Byte Order: In little-endian byte order, the least significant byte of the 32-bit pattern is stored at the lowest address in memory. The remaining bytes are stored in ascending order of significance. Using the same pattern 0x12345678, the least significant byte (0x78) would be stored at the lowest memory address, followed by 0x56, 0x34, and finally 0x12.

So, depending on the computer’s architecture and its chosen byte order, the 32-bit pattern will be stored in memory accordingly.

It’s important to note that within a byte, the order of the individual bits remains the same across all computers. The difference lies in how the bytes are arranged when multiple bytes are used to represent a larger data type, such as a 32-bit integer.

What is this range [1, SECP256k1n− 1]

The order represents the number of points on the curve that satisfy the elliptic curve equation. In the case of SECP256k1n, the order is a very large number.

The mathematical equation of the Elliptic Curve that we are talking about is 

y² = x³ + 7

When we say “SECP256k1n,” we are referring to the order of the curve. 

It represents the total number of points on the SECP256k1n curve. This number is very large.

secp256k1n = 115792089237316195423570985008687907852837564279074904382605163141518161494337

The “SECP256k1n − 1” is simply the value obtained by subtracting 1 from the order of the curve. 

ECDSA Literature

You can check out the literature here. 

Read Section 6.2 and Section 7 for the details of the algorithmic functions defined below. 

You might have heard about v, r, s while learning about signatures in solidity. Have you wondered what those are? Let’s see

There exist 3 functions that were defined in the formal paper of ECDSA literature of 2001.

 These functions are algorithms that are defined for 

1. Public Key Validation 
2. Proof of Possession of Private Key 
3. ECDSA Signature Generation and Verification

1. ECDSAPUBKEY ( Explicit Validation of Public Key )  – ( p_r ∈  B₃₂) ≡ p_u ∈  B₆₄
   In simpler terms, the ECDSAPUBKEY function takes a private key (p_r ) represented as a 32-byte array ( B₃₂ ) and produces a public key (p_u) represented as a 64-byte array ( B₆₄ ).

2. ECDSASIGN (ECDSA Signature Generation) – (e ∈ B₃₂, pr ∈ B₃₂) ≡ (v ∈ B₁, r ∈ B₃₂, s ∈ B₃₂)
   This function denotes the signing operation. It takes two inputs: the message hash e and the private key p_r. Both e and p_r are typically represented as 32-byte arrays (B₃₂).
   On the right-hand side, (v ∈ B1, r ∈ B32, s ∈ B32) represents the resulting signature. The component v is a single byte (B₁) representing the recovery id. The components r and s are both 32-byte arrays (B₃₂) representing the signature values. The equation implies that by applying the ECDSA signing operation with the given message hash e and private key pr, we obtain a signature consisting of the recovery id v, the r component, and the s component. This signature can be used for verification and authentication purposes.

3. ECDSARECOVER (ECDSA Signature Verification)
   (e ∈ B₃₂ , v ∈ B1, r ∈ B₃₂, s ∈ B₃₂) ≡ pu ∈ B₆₄
   represents the process of recovering the public key from a signature using the ECDSA
   
   It takes four inputs:
   a.  the message hash e (represented as a 32-byte array B32),
   b.  the recovery id v (represented as a single byte B1),
   c.  the r component of the signature (represented as a 32-byte array B32),
   d.  and the s component of the signature (represented as a 32-byte array B32).
   
   The public key is derived from the provided signature and can be used for verification and identification purposes.

4. In the ECDSA key recovery operation with the given message hash e, recovery id v, r component, and s component of the signature, we obtain the recovered public key pu in the form of a 64-byte array.

5. The public key is formed by the concatenation of two positive integers that should be smaller than 2²⁵⁶
6. v is the recovery identifier. The signature alone does not provide information about the public key that corresponds to the private key used for signing.
   1. To recover the public key from the signature during verification, the recovery identifier v is employed. It helps determine the possible public keys that could have been used to generate the signature. This is a 1-byte value that specifies the finiteness of the coordinates of the curve point where r is the x coordinate.
   2. The range of this value will be [ 0, 3 ]. but only the values 0 and 1 are typically used.
      1. The upper two possibilities, 2 and 3, are declared invalid because they represent infinite values on the elliptic curve. These infinite values do not correspond to valid curve points and cannot be used to reconstruct the public key.
7. The ESDSA signature will be considered invalid if the following conditions are true.
   0 < r < secp256k1n
   0 < s < secp256k1n ÷ 2 + 1
   v ∈ {0, 1}

Conclusion

Digital signatures are a fundamental tool for securing digital communication and ensuring data integrity. They provide a way to verify the origin and integrity of messages, ensuring trust and confidentiality in various applications. By combining public-key cryptography, hashing, and encryption, digital signatures enable secure interactions in today’s interconnected world.