The ECDSA Signatures

September 17, 2025

ECDSA : The Power House of the Web3.

ECDSA stands for Elliptic Curve Digital Signature Algorithm. At its core, it’s a cryptographic algorithm that allows a person (or a program acting on their behalf) to digitally sign a piece of data. This signature serves three critical purposes in Web3:

1. Authentication (Who signed it?): It proves that the signer is indeed the rightful owner of the private key associated with a specific public key (and thus, a specific address on a blockchain).

2. Integrity (Has it been tampered with?): It guarantees that the signed data has not been altered since it was signed. Even a single bit change will invalidate the signature.

3. Non-repudiation (Can they deny it?): Once a transaction or message is signed, the signer cannot later deny having signed it. This provides irrefutable proof of their action.

Why is ECDSA so crucial in Web3? (The Purpose)

Imagine a world without digital signatures in Web3. It would be chaos! Every transaction, every interaction, every asset transfer would be vulnerable to fraud and manipulation. ECDSA solves this by providing a robust and efficient mechanism for:

• Securing Transactions: This is ECDSA’s most prominent role. When you send cryptocurrency, interact with a DeFi protocol, or mint an NFT, you’re essentially signing a transaction. This signature authorizes the action, ensuring only you (with your private key) can initiate it. Without it, anyone could move your funds!

• Proving Ownership of Assets: Your crypto wallet address is derived from your public key, which is mathematically linked to your private key. By signing a message with your private key, you can cryptographically prove that you control the associated address and, by extension, any assets held there. This is vital for things like proving NFT ownership or participating in decentralized autonomous organizations (DAOs).

• Enabling Decentralized Identity: In Web3, your identity can be linked to your cryptographic key pairs. ECDSA allows you to sign claims, attestations, or data, establishing a verifiable, self-sovereign identity without relying on a central authority.

• Facilitating Secure Communication: Beyond transactions, ECDSA can be used to sign any message, ensuring its authenticity and integrity. This is important for secure communication between users or dApps on a decentralized network.

• Efficiency for Blockchain Networks: Compared to older digital signature algorithms like RSA, ECDSA offers the same level of security with significantly smaller key sizes. This translates to smaller transaction sizes, faster processing, and lower computational costs – all vital for the scalability and efficiency of blockchain networks.

• Trust in a Trustless Environment: Web3 aims to minimize the need for trusted intermediaries. ECDSA is a fundamental building block for achieving this “trustless” paradigm, as it allows participants to cryptographically verify actions without relying on a central authority to vouch for them.

What are Digital Signatures ?

A digital signature is a mathematical scheme for verifying the authenticity and integrity of digital messages or documents. It’s a piece of data (the “signature”) generated by a signer using their secret private key, which is then attached to the message. Anyone can then use the signer’s public key to verify that the message indeed came from that specific signer and has not been altered since it was signed.

The Core Purposes of the Digital Signatures

Digital Signatures solves three fundamental problems in digital communication and transactions :

1. Authentication

   • It confirms the identity of the signer like, who signed it ?

2. Integrity

   • To ensure that the signed message has not been changed since it was signed.

3. Non-repudiation

   • To prevent the signer from later denying that they signed a particular message .

How Digital Signatures Work ?

1. Key Pair Generation: The signer (e.g., you) first generates a pair of mathematically linked keys:

   • A private key (secret): This is a large, randomly generated number that only you should know. It’s used to create signatures.

   • A public key (public): This is derived from your private key and can be freely shared. It’s used by anyone to verify signatures made by your private key.

2. Hashing the Message: The message or data that needs to be signed (e.g., a transaction, a document, an email) is first put through a cryptographic hash function. This function takes the message of any size and produces a fixed-size, unique “fingerprint” called a hash value . Even a tiny change in the message results in a completely different hash

3. Signing (with Private Key): The signer then uses their private key and the hash value to run a special signing algorithm (like ECDSA). This algorithm produces the digital signature (e.g., the (r, s) pair that are explined below).

4. Verification (with Public Key):

   Signing:

   1. The signer takes the message.
   
   2. They compute a hash of that message (e.g., hash_A = H(Message)).
   
   3. They generate the signature using their private key and hash_A.
   

   Verification:

   1. The verifier receives the Message (the presumed original message) AND the Signature.
   
   2. The verifier must independently compute the hash of the received Message (e.g., hash_B = H(Message)).
   
   3. The verification algorithm then checks if the Signature is valid for hash_B using the signer's public key.
   

If even a single bit of the Message is changed between signing and verification, then hash_B will be completely different from hash_A. The verification algorithm will then fail, indicating that the message has been tampered with.

Lets go deep into the working of ECDSA

The ECDSA is a signature algorithm based on Elliptic Curve Cryptography (ECC) . The specific curve used in ECDSA is the Secp256k1 curve , It was chosen for it’s interoperability with THE BITCOIN , it’s efficiency and security and this elliptic curve is symmetric about it’s X-axis , therefore for every co-ordinate on the curve there exists another co-ordinate at the same point ‘x’ point .

This is a graph of secp256k1’s elliptic curve y2 = x3 + 7 over the real numbers

ECDSA is used to :

• Generate Key pairs
• Create Signatures
• Verify Signatures

Wait ! before that , let’s know about constants in Secp256k1 curve

Constants in Secp256k1 curve: These are often called the domain parameters of the curve.

1. p (The Prime Modulus of the Finite Field):

   • What it is: This is a very large prime number that defines the “size” of the finite field over which the elliptic curve equation y^2=x^3+7 operates. All calculations (addition, multiplication, etc.) involving the coordinates of points on the curve are performed modulo p.
   • Value for secp256k1: In hexadecimal p:

   0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
   

   In decimal p:

   115792089237316195423570985008687907853269984665640564039457584007908834671663
   

   • Purpose:
   • Finite Set of Points: Instead of an infinite curve over real numbers, p ensures that there is a finite, but very large, number of discrete points on the curve. This is crucial for digital computations.
   • Modular Arithmetic: All x and y coordinates of points on the curve must be integers between 0 and p-1. Operations like addition and multiplication of these coordinates “wrap around” when they exceed p, behaving like a clock.
   • Security: The size of p (256 bits) directly contributes to the cryptographic strength, making it computationally infeasible to brute-force values or solve the Elliptic Curve Discrete Logarithm Problem (ECDLP).

2. G (The Generator Point / Base Point):

   • What it is: This is a specific, publicly agreed-upon point on the secp256k1 curve. It has fixed (Gx, Gy) coordinates.
   • Value for secp256k1:

   G = 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798
   
   483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
   

   • Purpose:
     • Starting Point for Key Generation: G is the “origin” or “starting point” for generating all public keys. Your public key is derived by performing scalar multiplication of your private key (a secret integer d) with the generator point G:Q=d⋅G Where Q is your public key (a point on the curve), d is your private key (a scalar), and G is the fixed generator point.
     • Building Block for Operations: Almost all elliptic curve operations, including public key generation, signature generation, and verification, ultimately involve scalar multiplication and point addition/doubling operations starting from G.
     • Consistency: Since G is a publicly known and fixed constant, everyone using secp256k1 can consistently derive and verify public keys and signatures.

3. n (The Order of the Generator Point / Subgroup Order):

• What it is: This is the smallest positive integer n such that when the generator point G is added to itself n times, it results in the “point at infinity” (the identity element of the elliptic curve group). In simpler terms, n is the number of unique points you can reach by starting at G and repeatedly adding G to itself.

• Value for secp256k1:

n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

• Purpose:
  • Defines the Size of the Private Key Space: Your private key d must be chosen as a random integer between 1 and n-1. This n defines the vastness of the possible private keys.
  • Underpins Security: The security of ECC relies on the difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP), which is the problem of finding d given Q and G (i.e., finding d from Q=d⋅G). The larger n is, the harder this problem becomes. For secp256k1, n is a 256-bit prime number, which provides sufficient security against known attacks.
  • Modular Arithmetic for Scalars: Many scalar operations in ECDSA (like s = k^{-1} (h + d \cdot r) \pmod n) are performed modulo n, not p.

Now back to ECDSA

While the elliptic curve secp256k1 is symmetric about its x-axis, allowing for two y-coordinates for a given x, the signature components r and s are not direct coordinates of the public key or private key on the curve. Instead:

• r is the x-coordinate of an intermediate point (calculated during the signing process).
• s is a scalar value derived from the private key, message hash, and r. Serves as proof of the signers knowledge of the private key and is calculated using a random constant k which ensures that the signature is unique everytime .
• v is a recovery ID (a single byte) that, along with r and s, allows for the deterministic recovery of the original public key and represents the index of the point on the elliptic curve whether the point is the positive Y-axis or negative Y-axis -> known as POLARITY.

How are the Private and Public keys generated ?

• The Private key is generated on a random integer within in the range 0 to n-1 (where n is the order that we discussed earlier)
• The Pubic key is an elliptical curve point calculated by timesing the private key with the generator point G (publicKey = privatekey * G)

How do we know that ECDSA private keys are secure ?

The security of ECDSA private keys, and indeed of all Elliptic Curve Cryptography (ECC), fundamentally relies on the presumed computational intractability of the Elliptic Curve Discrete Logarithm Problem (ECDLP). To understand this , it is better to know about the point addtion and group operation in math .

As ,i am not much intrested in math , Lets make it simple:

Public Key = P ⋅ G

where , P -> Private Key

• Here , we are doing scalar multiplication where we add a point to itself multiple times , so we are adding G which is a point on the elliptic curve to itself P times .
• In normal arthemetic we can derive P , like

Public Key / G = P

But in elliptic curve groups there is no concept of multiplication , inverse multiplication (aka division) . So there is no way of calculating the Inverse and therefore calculating the Private key is computationally infeasable .

How is a signature created ?

Signatures are created by combining the hash of a message with the private key using the ECDSA algorithm

firstly , Using SHA256 hashing algorithm we hash the message then secondly , we generate a securely random number K (the nonce) , we then calculate a point R which is R = K ⋅ G and takes it’s x co-ordinate

-> R = K ⋅ G
-> R = (x,y)
-> r = x mod n

So we got our r which is a part of digital signature.

Now s is calculated using the following formula

s= k^-1 (hash(message)+private key ⋅ r ) modn

In modular arithmetic, there isn’t a “positive” or “negative” Y-axis in the same way as real numbers. For each valid x-coordinate on an elliptic curve, there are generally two possible y-coordinates. The v parameter (often called recovery ID) indicates which of these two possible y-coordinates the original point R had, and also helps to disambiguate between two mathematically valid s values for a given r (due to signature malleability). It’s crucial for public key recovery.For Ethereum, v values are typically 27 or 28 (or higher with EIP-155) based on this information.

“Whew! My fingers are tired from all that typing, and yours are probably tired from all that scrolling. Let’s get to the short version before this blog becomes a bedtime story!”

How are ECDSA Signatures are verified ?

The ECDSA verification algorithm takes the original message , the signature from the signing the signing algorithm , and the public key and outputs a boolean value respresents whether the signature is valid or not .

This algorithm works in reverse of the signing algorithm and it is done by some formulas :

-> s1 = s^-1(mod n)
-> R1 = (hash * s1)G + (r * s1)public key
-> R1=(x,y)
-> r1 = x mod n
-> r1 == r ?  -- final check for validity

The EVM precompiler ecrecover does this for you in THE SMART CONTRACTS

ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)

It enables us to recover the Signers Etherium Address of a message that has been signed using their private key , using ECDSA and this what allows Smart contracts to verify the integrity of a signature and the recovery of the signer .

Using ecrecover directly can lead to some security issues (like signature malleability), it is better not using the ecrecover directly , therefore oppenzeppelin ECDSA library to validate signatures

Aside from Signature malleability the other issue with using ecrecover directly is that if the signature is invalid ecrecover will return zero address , if this is not handled correctly in the implementation of the smart contract then this can lead to issues , So this is needed to check if ecrecover is returning the zero address anfd then smart contract should revert .