Prerequisites: secp256k1, Finite Fields, and Elliptic-Curve Point Operations#

Because this involves a great deal of modular arithmetic and elliptic-curve point operations, I have prepared some prerequisite material (and included what I learned along the way, lol). Of course, you can skip it if you are already familiar with these concepts.

Alternatively, you can also look at my conversation with Gemini for additional context (honestly, AI has made learning much faster

Signing and Verifying with an EOA Wallet#

As described in the previous article, when an EOA wallet needs to prove ownership of an address, the following process takes place:

1. A SWIE-compliant message is sent by the frontend to the wallet with a signature request.

2. When the wallet receives such a signature request, it displays a prompt asking for the user’s approval.

3. Once the user confirms, the wallet begins the signing process:

   • First, the SIWE message is processed using keccak-256 to produce a 32-byte hash $e$ for the subsequent calculations.

   • Next, given the wallet’s private key $d$, the finite field $p$ of secp256k1, its standard base point $G$, and the order $n$ of $G$, the wallet generates a random number $k$ within [1,n-1] for the subsequent verification calculations. Note that because only the values in [1,n-1] within n are usable, non-repeating results, calculations involving scalar selection and similar operations use mod n, while calculations over secp256k1 itself are performed within its defined field p, i.e. mod p.

   • The final signature is actually the concatenation of the three calculated values $r/s/v$, containing 32 bytes, 32 bytes, and 1 byte respectively. They are calculated as follows:

     • $R = kG = (R_{x}, R_{y})$

     • $r = R_{x} \bmod n$

     • $s = k^{-1} * (z + r * d) \bmod n$

     • $v$ exists because, for a secp256k1 elliptic curve

       $$y^2 = x^3 + 7 \bmod p$$

       at $x=R_x$, apart from the point at infinity $0$, there are two solutions reflected across the x-axis. By providing 0 or 1, $v$ specifies the yParity that determines which solution should be selected. Of course, secp256k1 also permits the case where $r+n<p$, but because its probability is extremely low, the EVM does not account for this case during recovery in practice.

   • This produces the final signature $r/s/v$, which the wallet returns to the server.

4. The server then verifies the received $r/s/v`. At this point, the server knows the secp256k1 base point$G$, the SIWE message sent to the wallet and its keccak-256 hash$e$, and the signature$r/s/v$ returned by the wallet.

5. The server then begins verification:

   • The server now has $G$ / $e$ / $r$ / $s$ / $v$. It needs to determine whether the wallet address calculated from these values matches the wallet address received at the beginning. According to

     $$address = keccak256(Q_x || Q_y)[12\:32]$$

     (that is, the address consists of the final 20 bytes of the keccak-256 hash of the public key $Q$), the current goal is to calculate the public key $Q$ from the available information.

   • In addition to the data above, we also know how $s$ was derived through integer calculations in the scalar field:

     $$s = k^{-1} * (z + r * d) \bmod n$$

     We can therefore rearrange it as:

     $$d = r^{-1} * (s*k - z) \bmod n$$

     We then move into the domain of elliptic-curve point operations and multiply both sides of the equation by the base point $G$:

     $$\begin{aligned} dG &= \left(r^{-1}(sk - z) \bmod n\right)G \\ &= r^{-1}(skG - eG) \end{aligned}$$

     We also know that the public key $Q = dG$ and $R=kG`. Since we know$r=R_x$, we can recover$R$using$v$. We can therefore transform the expression above into an equation for the public key$Q$ that consists entirely of known values:

     $$Q = r^{-1}(sR - eG)$$

     This gives us the calculated public key $Q$ of the wallet that produced the signature.

   • We can then apply keccak-256 to the recovered public key $Q$ and take the final 20 bytes to obtain the wallet address used for verification. This address is compared with the address provided earlier. If they match, control of the wallet can be verified using only the available information, without knowing the private key $d$. At the same time, because $Q=dG \bmod n$ is an elliptic-curve operation (under mod n), the result of $dG$—where d is within $n$, a large prime close to $2^{256}$—can be reached quickly through repeated addition. Deriving d from Q, however, is the elliptic-curve discrete logarithm problem on secp256k1. There is currently no practical algorithm capable of solving it with realistic resources: generic attacks have a complexity of approximately $2^{128}$, while according to thermodynamics, even all the energy in the universe would be insufficient to perform $2^{256}$ computations. This makes the problem effectively unsolvable in engineering practice.

     Tip: Actual EVM verification also validates fields such as domain/address/chainId within the SIWE message. This article mainly discusses the mathematical implementation, so those checks are omitted here.

6. In this way, the server and wallet can confirm wallet ownership using only the signature, the SIWE message, and some defined mathematical information, without exposing the private key.

Conclusion#

The above is roughly the mathematical proof behind wallet signing and verification. Although it may apparently need to change soon given Google’s advances in quantum computing, there should still be plenty of time, and there is no harm in learning the classics (

That is all. This is essentially a supplement covering the theoretical foundation behind the engineering practice of wallet signature verification.