2025.06.20

【CTO Tech Blog】3ラウンドのECDSA閾値署名プロトコルDKLS23

CTO Tech blog

ECDSAベースの閾値署名というと、GG18/20あたりが有名↓

techmedia-think.hatenablog.com

これらのプロトコルは加法準同型性のある暗号化方式であるPaillier暗号に依存しており、署名の生成に6ラウンドの通信を必要とする。

その後提案されたDKLS23という署名スキーム↓は、準同型暗号の代わりに紛失通信を活用した閾値署名スキームで、署名生成が3ラウンドで行えるというメリットがある。

eprint.iacr.org

DKLS23

まず最初に分散鍵生成とゼロシェアのセットアップを行う。

鍵生成プロトコル

GG18/20など従来の閾値署名プロトコルの分散鍵生成（DKG）は、PedersenのVSSなどが採用されていたけど、DKLS23ではRelaxed DLog Keygenという鍵生成プロトコルを採用している。

参加者の数をn、閾値をtとした場合、鍵生成の流れは↓

1.各参加者 $P_{i}$ はそれぞれランダムな多項式 $p_{i} (x)$ を選択する。また多項式を評価してベースポイントを乗算した値を $P_{(} x) = p (x) G$ とする。

2. 各参加者 $P_{i}$ は、 $k \in [0, t - 1]$ について $P_{i} (k)$ を計算し、

3.2に対するコミットメント $c o m m i t m e n t_{i} = H (P_{i} (0) | | . . . | | P_{i} (t - 1) | | s a l t)$ を計算し、他の参加者に共有する。※ ここでは閾値の数分のコミットメントだけを計算し、全員に共有する。

4.次に各参加者は参加者全員分（n人分）の多項式の評価値 $p_{i} (j)$ （つまりシェア）を計算し（2は楕円曲線上の点だけど、こちらはスカラー値のまま）、そのコミットメント $H (p_{i} (j) | | s a l t_{i, j})$ を計算し、そのコミットメントを各参加者 $P_{j}$ に個別に送信する。

5.参加者全員から、3と4のコミットメントを受け取ったら、コミットした値をデコミットする。
○2のコミットメントについては、それぞれ $P_{i} (0) | | . . . | | P_{i} (t - 1) | | s a l t)$ をブロードキャストして開示する。
○4のコミットメントについては、それぞれ $p_{i} (j), s a l t_{i, j}$ を個別に開示する。

6.参加者iからデコミットされたデータを受け取った各参加者jは以下の検証を行う。
○ブロードキャストされた楕円曲線上の点を使ってラグランジュ補間を行い $P_{i} (j)$ を計算し、
○個別開示された $p_{i} (j) \cdot G$ が先に受け取ったコミットメントと一致するか検証し、かつラグランジュ補間で導出した点と一致するか検証する。

7.検証をパスしたら、全参加者がブロードキャストしたt個の点の先頭の点、つまり $P_{i} (0)$ を合算して、公開鍵とする。つまり、各参加者が生成した多項式の定数項の点を合算した点が公開鍵。

これで各参加者がそれぞれ秘密鍵のシェア $p (i)$ を持つ状態になる。

PedersenのVSSと比較すると、ラウンド数が少なく、コミットメント作成時の楕円曲線演算の数が少なく、自身が秘密鍵を知っていることの証明を必要としないなど、効率的。ただ、論文では、

We stress that our relaxed key generation functionality is sufficient for use with the signing protocol proposed in this work, but it cannot necessarily be used with other threshold signing protocols that use discrete-log keypairs.

とあり、DKLS23で使用する分には十分だけど、他の閾値署名プロトコルで必ずしも使えるとは限らないと。

Relaxedとあるのは、実際に署名を作成する際のラウンドで、以下のゼロシェアを使って秘密鍵のシェアを再ランダム化するので、秘密鍵の知識の証明が求められるのはそこ（署名の第3ラウンドの一貫性チェック）まで遅延されることが由来。

ゼロシェアのセットアップ

二者間で共有される秘密のランダム値であるペアワイズシードを生成する。

アリスとボブで生成する場合、

1.両者はそれぞれランダムなシードを選択する（アリスのシードを $s e e d_{a b}$ 、ボブのシードを $s e e d_{b a}$ ）とする。

2.両者は1のシードのコミットメントcommitmenta=H(seedab|noncea)
、commitmentb=H(seedba||nonceb)を計算し、自分が計算したコミットメントを相手に送る。

3.コミットメントを交換したら、それぞれコミットしたシードを相手に開示する。

4.両者は自分のシードど相手のシードのXORを計算し共有シード
$s h a r e d - s e e d_{a, b} = s e e d_{a b} \oplus s e e d_{b a}$ を計算する

上記のペアワイズシードを署名の全参加者分、それぞれ協力してセットアップする。

ゼロシェアというのは、すべてのシェアを加算するとその結果がゼロになるシェアのことで、署名プロセスで各参加者が上記のペアワイズシードを元に導出する。たとえば3人でゼロシェアを生成する場合、参加者 $P_{1}, P_{2}, P_{3}$ は、それぞれ

●P1：shared−seed1,2、shared−seed1,3
●P2：shared−seed1,2、shared−seed2,3
●P3：shared−seed1,3、shared−seed2,3

を持っているので、以下のようにゼロシェアを計算できる。

●P1：share1,2=−H(shared−seed1,2||sigid)、share1,3=−H(shared−seed1,3||sigid)
そしてζ1=share1,2+share1,3とする。
●P2：share2,1=H(shared−seed1,2||sigid)、share2,3=−H(shared−seed2,3||sigid)
そしてζ2=share2,1+share2,3とする。
●P3：share3,1=H(shared−seed1,3||sigid)、share3,2=H(shared−seed2,3||sigid)
そしてζ3=share3,1+share3,2とする。

各シェアの値について、IDが小さい方の符号がマイナスとするルールを設けることで、上記シェアをすべて加算するとその合算値（ $\sum ζ_{i}$ ）がゼロになることが保証される。そして一度セットアップしておけば、署名時にsigidによって、何回でも決定論的に異なるゼロシェアを導出できる。

署名プロトコル

前提として、2P-ECDSAやGG18/20ではPaillier暗号を使って乗法シェアを加法シェアに変換していた（MtA）が、DKLSの署名プロセスではPaillier暗号に代わってVOLEを利用する↓

techmedia-think.hatenablog.com

公開鍵をP = xG（xは秘密鍵）、署名対象のメッセージをm、ハッシュ関数をH、楕円曲線のベースポイントをGとした場合、通常、ECDSA署名は以下のように生成される。

1.ランダムなnonce値kを選択し、

2.公開nonce R = kGを計算し、r = R.x（点RのX座標）とする。

3.を計算し、

4.(r, s)がECDSA署名

DKLS23では、上記のECDSAのsを求める式を以下のように分解する。

$w = (H (m) + r \cdot x) \cdot ϕ$ 、

$u = k \cdot ϕ$ とし、

3.sは、 $s = \frac{w}{u}$

$ϕ$ はランダムなマスク値で、最終的なsの計算結果自体は変わらない。

DKLS23の署名プロトコルは、以下の3つのラウンドで構成される。

第1ラウンド

第1ラウンドでは、各参加者は、署名に使用するnonceのシェアにコミットする。

各参加者iは、それぞれ

1.ランダムな値 $k_{i}, ϕ_{i}$ を選択し、
2.公開nonce $R_{i} = k_{i} G$ を計算し、
3.他の参加者（j）へのコミットメント $c o m m i t m e n t_{i, j} = H (R_{i} | | s a l t_{i, j})$ を計算する
4.他の参加者へ3のコミットメントと送信し、二者間のVOLEをセットアップする
5.ゼロシェア $ζ_{i}$ を計算する

$ϕ_{i}$ をサンプリングしたりゼロシェアを計算してるけど、この値が実際に使われるのは次のラウンド。

第2ラウンド

第2ラウンドは、秘密の値のMtA変換とその正しさの証明準備をするラウンド。また、第1ラウンドでコミットした各公開nonceのシェアをデコミットする。

参加者iは、

1.保持する秘密鍵のシェア $p (i)$ とゼロシェア $ζ_{i}$ を使って秘密鍵のシェアを再ランダム化する。具体的には、 $s k_{i} = p (i) \cdot ラグランジュ係数 + ζ_{i}$ を計算する。

2.2つの要素のベクトル $(k_{i}, s k_{i})$ を入力として、他の参加者jとVOLEを実行する。その際、参加者jはランダムな値 $χ_{j, i}$ を選択し、両者はcui,j+duj,i=ki⋅χj,iおよびcvi,j+dvj,i=ski⋅χj,iを満たす加法シェアを得る。VOLEを利用することで、(ki,ski)に対して同じ値が乗算される。
○参加者iは、(cui,j,cvi,j)を保持
○参加者jは、(duj,i,dvj,i)を保持

3.VOLEの結果、以下を計算する。この時、 $χ_{i, j}$ は、2のVOLEをj基点で行った際にiがランダムに選択する値。
○Γui,j=cui,j⋅G
○Γvi,j=cvi,j⋅G
○pki=ski⋅G
○ψi,j=ϕi−χi,j

4.最後に、第1ラウンドでコミットした公開nonce Riと、3で計算した値を参加者jに送る。

第3ラウンド

最後のラウンドでは、第2ラウンドで受け取ったデータの検証を行い、最終的な署名を組み立てる。

参加者iは、

1.jから受け取ったデータについて、以下の一貫性チェックをすることで、VOLEでjの $(k_{j}, s k_{j})$ に対して自分が選択したランダム値 $χ_{i, j}$ との積の加法シェアの正しさを検証する。
○χi,j⋅Rj−Γuj,i=dui,j⋅G
○χi,j⋅pkj−Γvj,i=dvi,j⋅G

$\sum p k_{i}$ を計算し、全体の公開鍵と合致するかチェックし、ゼロシェアで再ランダム化されていることを検証する。

3.↑のチェックをパスしたら、署名参加者から受け取った公開nonceを合算して署名に使用する公開nonce $R = \sum R_{i}$ を導出し、r = R.xとする。

4.続いて、以下の値を計算する。
○ui=ki⋅(ϕi+∑ψj,i)+∑(cui,j+dui,j)
○vi=ski⋅(ϕi+∑ψj,i)+∑(cvi,j+dvi,j)
○wi=H(m)⋅ϕi+r⋅vi

5.他の参加者に署名の断片 $w_{i}, u_{i}$ を送信する。

7.(r, s)を検証し、正しければ署名データの完成

以上がDKLS23の署名プロトコル。

ブログ元記事へのリンク

ブログの元記事はこちらから

当HPでは数式などが正しく表記されていない可能性がございます。
ぜひ元記事をご確認ください。

https://techmedia-think.hatenablog.com/entry/2025/06/20/185741

Chaintopeでブロックチェーンの未来を共に創りませんか？

Chaintopeは、独自のブロックチェーン「Tapyrus」と、開発プラットフォーム「Tapyrus Platform」を活用し、デジタル社会の信頼基盤を構築しています。
私たちは、ブロックチェーン技術の可能性を最大限に引き出し、社会に新しい価値を提供することを目指しています。

募集職種：

ブロックチェーンエンジニア
アプリケーションエンジニア
インフラ・保守エンジニア
プロジェクトマネージャー
フィールドセールス

Chaintopeで働く魅力：

最先端のブロックチェーン技術に触れる機会
リモートワークやフレックスタイム制による柔軟な働き方
専門性の高いチームとの協働
ブロックチェーン技術に情熱を持つあなたのスキルを、私たちのチームで活かしませんか？
詳細は、採用情報をご覧ください。

https://www.chaintope.com/recruit/

話題のキーワード

一覧にもどる