I need you to authenticate this information#

Now that the address requiring authentication is known, we can prepare a standard SIWE (Sign-In with Ethereum) login signing message. A message in roughly this format:

1
localhost:3000 wants you to sign in with your Ethereum account:
2
0xYourWalletAddress
3

4
Sign in to web3walletLogin with this wallet.
5

6
URI: http://localhost:3000
7
Version: 1
8
Chain ID: 1
9
Nonce: <server-issued nonce>
10
Issued At: <generated timestamp>

Then this message is standardized according to EIP-191, to distinguish it from other signatures and ordinary transactions:

"\x19Ethereum Signed Message:\n" + len(message) + message

The implementation here comes from wagmi’s signMessageAsync, which performs the actual authentication request to the wallet.

1
const { signMessageAsync, isPending: isSigning } = useSignMessage();
2

3
// make a siwe message
4
const siweMessage = new SiweMessage({
5
      domain: window.location.host,
6
      address,
7
      statement: "Sign in to web3walletLogin with this wallet.",
8
      uri: siteOrigin,
9
      version: "1",
10
      chainId,
11
      nonce
12
    });
13
const preparedMessage = siweMessage.prepareMessage();
14
// send sign request to wallet
15
const signature = await signMessageAsync({ message: preparedMessage });

This is authentication that only my private key can produce#

When this message reaches the wallet requesting authentication, the wallet needs to ensure that its signature can prove its control over the address previously provided. At this point, the wallet needs to use its private key to encrypt the hash of the information just sent, while also ensuring that this signature can be verified by the website, which only knows the wallet address and the requested message. What is needed here is naturally a series of mathematical transformations to guarantee the validity of this verification method. Of course, here I am just using wagmi’s algorithm to verify the returned signature first (

1
// use the message (the client send) and sign(the wallet back)
2
const verifyResponse = await fetch("/api/auth/verify", {
3
      method: "POST",
4
      headers: {
5
        "Content-Type": "application/json"
6
      },
7
      body: JSON.stringify({ message: preparedMessage, signature })
8
    });
9

10
// sign message verify
11
const siwe = new SiweMessage(body.message);
12
const result = await siwe.verify({
13
    signature: body.signature,
14
    domain: expectedDomain,
15
    nonce: siwe.nonce
16
  });
17

18
// the fail result
19
if (!result.success) {
20
    return NextResponse.json({ error: "invalid signature" }, { status: 401 });
21
  }

As for the actual verification calculation?

That brings us to the secp256k1 curve used by EOA wallet signatures. For an EOA wallet, it is roughly like this:

• EOA private key: a roughly 256-bit random number d
• Public key: elliptic curve point Q = d * G
• Address: the last 20 bytes of keccak256(publicKey)
• Signature: ECDSA over secp256k1

However, I actually don’t really understand the actual computation in this part either (, but I roughly know that the reason the private key d cannot be reversed from the public key Q obtained via the signature and message hash is that it would be equivalent to solving the elliptic curve discrete logarithm problem $Q = d * G$, with a workload on the order of about $2^{128}$ (secp256k1 is a 256-bit-level curve).

In this way, using the returned signature ($r + s + v$) and the message hash that we sent, we can ultimately recover a public key and calculate an address from it. When this address matches the address provided earlier, it proves that this wallet has control over that address.