前提知識：secp256k1、有限体と楕円曲線上の点演算#

剰余演算と楕円曲線の点演算が大量に関わるので、少し前提知識を用意しました（ついでに自分で補った内容も載せていますwww。もちろん、すでに知っている場合は読み飛ばしても大丈夫です。

あるいは、補足として私とgeminiの会話を見てもよいです（正直、aiがあると学習速度がかなり加速します

Gemini

‎Gemini - direct access to Google AI

Created with Gemini

gemini.google.com/share/f72d7ecbcf76

EOAウォレットの署名と検証について#

前回の記事で述べた通り、EOAウォレットでアドレスの所有権検証が必要になった場合、次のような流れになります：

1. SIWEに準拠したmessageがフロントエンドからウォレットへ送られ、署名を要求する

2. このような署名リクエストをウォレットが受け取ると、ユーザーに同意を求めるプロンプトが表示される

3. ユーザーが確認すると、この時点でウォレットの署名フローが始まる

   • まず SIWE message に対して keccak-256 を計算し、以降の計算に使う32-byte hash $e$ を得る

   • 次に、ウォレットの秘密鍵 $d$ とsecp256k1の有限体 $p$、標準で選定された基点 $G$、および $G$ の位数 $n$ に対して、ウォレットは [1,n-1] の範囲内の乱数 $k$ を生成し、以降の検証計算を行う（ここで注意が必要なのは、n 内の [1,n-1] だけが利用可能な重複しない結果であるため、点を取るなどの計算では mod n が選ばれる一方、secp256k1 全体の範囲計算はその規定範囲 p で計算される、つまり mod p であるという点です

   • 最終的に生成される署名は、実際には $r/s/v$ という3つの計算結果を連結したもので、それぞれ32-byte/32-byte/1-byteの内容です。それらの計算内容は：

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

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

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

     • $v$ は、secp256k1楕円曲線

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

       において、$x=R_x$ 上の解は、無限遠点$0$を除けば、x軸に対して対称な2つの解が存在するため、ここで0/1を提供することでどちらの解を選ぶべきかを指定する yParity です（もちろん、secp256k1 では $r+n<p$ となる可能性もありますが、確率が非常に小さいため、EVMの実際の計算ではこのケースの復元は考慮されていません

   • こうして、ウォレットがサーバーへ返す最終的な署名 $r/s/v$ が生成される

4. 次に、サーバーは受け取った $r/s/v$ を検証する。この時点でサーバーが知っているのは、secp256k1 の基点 $G$ / ウォレットへ送信した SIWE message と、その keccak-256 によって計算された hash $e$ / ウォレットから返された署名 $r/s/v$

5. そしてサーバー側の検証が始まる：

   • サーバーにとって、現在すでに $G$ / $e$ / $r$ / $s$ / $v$ がある。この時点で、ここにあるデータから計算されたウォレットアドレスが、最初に受け取ったウォレットアドレスと同じかどうかを知る必要がある。そして

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

     （つまり、アドレスは公開鍵 $Q$ を keccak-256 で計算した結果の hash の後ろ20バイト）であることから、現在の目標は、今ある条件から公開鍵 $Q$ を計算することだと分かる

   • この時点で、上述のデータ以外に分かっているのは、$s$ の変換過程（スカラー体における整数計算）であり、すなわち

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

     したがって、同様に次の変形を得られる：

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

     そして計算は楕円曲線の点演算の領域に入り、上式の両辺に基点 $G$ を掛ける

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

     同時に、公開鍵 $Q = dG$、$R=kG$ であり、さらに $r=R_x$ であることが分かっている。そして $v$ によって $R$ を復元できる。これにより、上述の式を既知量だけで構成された公開鍵 $Q$ の求解式に変換できる

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

     こうして、計算によってこの署名ウォレットの公開鍵 $Q$ が求められる

   • その後、求めた公開鍵 $Q$ に対して keccak-256 を行い、末尾20バイトを取ることで、検証用のウォレットアドレスを得られる。そしてこのアドレスを事前に提供されたアドレスと比較し、両者が同じであれば、秘密鍵 $d$ を知ることなく、既存の情報だけに基づいて現在のウォレットの制御権を検証できる。同時に、$Q=dG \bmod n$ は楕円曲線（mod n 下）として、$dG$（d は $n$（$2^{256}$ に近い大きな素数）の中にある）の計算結果には累加法によって高速に到達できる一方、Q から d を逆算することは secp256k1 上の楕円曲線離散対数問題に属する。現在、現実的なリソース内で完了できる実行可能なアルゴリズムは存在しない<汎用攻撃の計算量はおよそ> $2^{128}$ レベルであり、熱力学によれば、$2^{256}$ の計算は宇宙の全エネルギーを使い切っても不可能であるため、工学的には解けないものとなる。

     tips：実際のEVM検証では、SIWE情報内部のdomain/address/chainIdなどの検証もありますが、ここでは主に数学的な実装について議論しているため、それらは省略します

6. これにより、サーバーとウォレットの間では、署名とSIWE message、そしていくつか定義済みの数学的情報だけを用い、秘密鍵を公開することなく、ウォレット所有権の確認が完了する

結び#

以上が、おおよそ一度のウォレット署名と検証における数学的な証明です。もっとも、googleの量子計算における発展によって、近いうちに変わるかもしれませんが、まだそれなりに時間はあるはずなので、古典的なものを学んでおいても問題ないでしょう（

以上、ウォレット署名検証のエンジニアリング実践における理論的基礎への補足、という感じです。