Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie MuSig
Ähnlich wie MuSig (17)
Mehr von takayaimai
Mehr von takayaimai (15)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
MuSig
- 1. MuSig — Simple Schnorr Multi-Signatures with Applications to Bitcoin — 【暗号通貨輪読会#16】MuSig @ 01Booster 2018/3/12 フロンティアパートナーズ合同会社 創業者&代表CEO United Bitcoiners Inc. 共同創業者&取締役CTO 今井崇也
- 2. 自己紹介 United Bitcoiners Inc. 共同創業者＆取締役CTO フロンティアパートナーズ合同会社 代表CEO マスタリングビットコイン、翻訳者代表 世界で初めての、日本語によるビットコイン・ブロッ クチェーンの詳細技術書(NTT出版社) 2016/7/14出版 電子書籍版(kindle)も オープンエディション版 https://www.bitcoinbook.info
- 3. 自己紹介 バックグラウンド 新潟大学大学院 素粒子理論物理 博士(理) カカクコム 検索エンジン開発 検索サーバクラスタ構築運用 大規模データ処理 機械学習 画像認識 データタワー株式会社 代表取締役
- 4. 今回の論文 Title: Simple Schnorr Multi-Signatures with Applications to Bitcoin Author: Gregory Maxwell, Andrew Poelstra, Yannick Seurin, and Pieter Wuille Article: https://eprint.iacr.org/2018/068.pdf Published: January 2018
- 6. この論文の方針 [論文のAbstractから] 新しいシュノア(Schnorr)ベースのマルチシグネチャスキーム（すなわち、署名者のグループが共通のメッセージに 短い署名を生成することを可能にするプロトコル）を説明しており、簡素公開鍵(plain public-key)モデルの中で証明 可能な安全性を持つものです。 プレイン公開鍵モデルとは、署名者には公開鍵を持つことのみが要求され、プロトコルに従う前に、公開鍵に対応 する秘密鍵の知識を証明機関または他の署名者に知らせる必要がないことを意味します。 本論文は、以下2つの点でBellare and Neven（ACM-CCS 2006）およびその変種 Bagarezandiら（ACM-CCS 2008 ）またはMaら（Des. Codes Cryptogr. 2010）の最先端スキームよりも改善されています。 （i）Bellare-Neven方式のように3回ではなく、標準的なシュノア署名と同じ鍵と署名サイズで2回の通信を行うだ けで、シンプルで効率的です。 （ii）鍵集約(キーアグリゲーション、key aggregation)を可能にします。これは、署名者の個々の公開鍵から計算す ることができる単一の「集約」公開鍵(aggregated public-key)に関して、合同署名(joint signature)が標準のシュノア 署名と正確に照合できることを意味します。 これは、標準的な離散対数問題より強い安全性仮定を課すワンモア離散対数問題(One More Discrete Logarithm, OMDL)を前提とし、分裂補題(フォーキングレンマ、Forking Lemma, Spliting Lemma)の2回の呼び出しによるより 緩やかなセキュリティ低下をもって行われます。 応用として、新しいマルチシグネチャスキームがビットコインのパフォーマンスとユーザーのプライバシーの両方 をどのように改善できるかを説明します。
- 7. Bitcoinのスケーリング問題 • Transactions in one block is full • 1MB per block • Increase of Bitcoin blockchain data size • High TX fee • ex. 360 satoshi / byte • ~ 7 TX per second • 10 min block time • 1 Mbytes / 256 bytes / 10 min / 60 second = 6.8 TX per second • This block time is necessary for stable Bitcoin blockchain and is enough for usual bitcoin payment. • But it is very slow comparing with credit card or NFC. • …
- 9. 160GB
- 10. 4.6tx/sec
- 12. いろいろな解決策 オンチェーン側 サイドチェーン/ドライブチェーン SegWit (Segregated Witness) ビッグブロック シュノア署名(Schnorr Signature) オフチェーン側 ライトニングネットワーク
- 15. シュノア署名(Schnorr Signature) Schnorr署名(オリジナル) 参考: 日向さんの説明 https://blog.visvirial.com/articles/721#i-10
- 16. シュノア署名(Schnorr Signature) 記述法 G: p次巡回群 g: Gの生成元 m: 署名対象メッセージ x: 秘密鍵(整数) X: 公開鍵, X = gx H(・): ハッシュ関数 署名作成 乱数rを選ぶ([0,p-1]) R = gr mod p c = H(X, R, m) 注: これに違和感を感じる方がいると思います。通常はc = H(R, m)。 s = r + cx mod p このとき、署名を(R, s)とする。 注: c, s, 署名に違和感を感じる方がいると思います。通常c = H(R, m)、s = r - cx 、署名は(c, s)。署名についてはp22 Discussionにて 議論。 署名検証 gs = RXc が成り立つかどうかを確認。成り立てば署名は正しい。成 り立たなければ署名は不正 注: 論文ではこうなってます。通常と違う署名検証等式です。また fiat-shamir変換は不要？というのも疑問点です。
- 18. シュノア署名の シンプルなマルチシグネチャ拡張 記述法 G: p次巡回群 g: Gの生成元 m: 署名対象メッセージ i: 署名者に振った番号([1, n]) xi: 秘密鍵, {x1, …, xn} Xi: 公開鍵, {X1=gx1, …, Xn=gxn} (x1はx1の意味) H(・): ハッシュ関数 署名作成 乱数riを選ぶ([0,p-1]) Ri = gri mod p R = R1R2…Rn X~ = X1X2…Xn , (X~ の~はXの上の意) c = H(X~, R, m) si = ri + cxi mod p s = s1+s2+…+sn このとき、署名を(R, s)とする。 署名検証 gs = RXc が成り立つかどうかを確認。成り立てば署 名は正しい。成り立たなければ署名は不正
- 19. 比較 署名集約なし 署名作成 乱数rを選ぶ([0,p-1]) R = gr mod p c = H(X, R, m) s = r + cx mod p このとき、署名を(R, s)とする。 署名検証 gs = RXc が成り立つかどうかを確認。成り立てば署 名は正しい。成り立たなければ署名は不正 署名集約あり 署名作成 乱数riを選ぶ([0,p-1]) Ri = gri mod p R = R1R2…Rn X~ = X1X2…Xn , (X~ の~はXの上の意) c = H(X~, R, m) si = ri + cxi mod p s = s1+s2+…+sn このとき、署名を(R, s)とする。 署名検証 gs = RXc が成り立つかどうかを確認。成り立てば署 名は正しい。成り立たなければ署名は不正
- 20. キーアグリゲーションで問題となる攻撃 — Rogue Key 攻撃 — Rogue Key攻撃 Alice(善人): 公開鍵Xa、Bob(悪人): 公開鍵Xb 集約公開鍵を作るときに、AliceはBobに公開鍵を送る。 次に、BobはXbをAliceに送るのではなく、Xb/XaをBobの公開鍵として送る。 Aliceは集約公開鍵(本当はXaXb、しかしXb/Xa*Xa = Xbになっている)を作成し、このアドレスへの支払いと してトランザクションをブロードキャスト BobはXbに対応した秘密鍵xbを使ってさきほどのトランザクションに対する署名を作成し、Aliceに無断で トランザクションを使えてしまう 簡易的な解決方法 Bobが送ってきた公開鍵に対する秘密鍵をBobが間違いなく持っていることを証明する手段を持つこと(認 証機関等)
- 22. ちょっと横道(key prefixed) 通常のシュノア署名に出てくるのは以下の形 c = H(R, m) この論文ではこう。 c = H(X, R, m) これをkey prefixedスキームという。
- 23. 本論文での提案方法
- 24. シンプルなものと何が違う ？ ハッシュ関数を２種類用意 H0、H1 cを以下に変更 c = H1(X~, R, m) 集約公開鍵を以下に変更 X~ = X1 a1X2 a2…Xn an ai = H0(<L>, Xi) L = {X1, …, Xn} <L> = unique encoding(L) 論文リファレンス[BN06]のような予備的コミッ トメントフェイズをなくした OMDL(ワンモア離散対数問題, One More Discrete Logarithm)を前提としないといけな い(解釈を間違えているかもしれません) これは通常の離散対数問題よりも、より解き 難い問題 cの計算を２つに分けることで、ハッシュ関数 が２つになり、セキュリティ証明で分裂補題 (Forking Lemma)を２回使わないといけない これによって、証明できるセキュリティ強度 が下がってしまう(解釈を間違えているかも しれません。この場合のセキュリティ強度の 定義がまだ自分の中であやふやです)
- 27. ECDSAだと署名集約はできない ？ 2人の署名者 s1, R1, c, a1, x1, X1 s2, R2, c, a2, x2, X2 このとき、以下が成り立つ gs1=R1X1 a1*c, gs2=R2X2 a2*c s=s1+s2, R=R1R2, X~=X1 a1X2 a2とすると、辺々同士をかけて gs=R1X1 a1*cR2X2 a2*c=R1R2X1 a1*cX2 a2*c=R(X1 a1X2 a2)c=RX~c (この逆の証明も必要なはず。逆は成立しない？)
- 29. もっとシンプルにはできない ？ ai = 1はダメ この場合は単純な拡張に一致してしまい、Rogue Key攻撃から脆弱になる ai = H0(Xi)もダメ 悪人署名者数が十分大きいと、攻撃者はWargnerのアルゴリズム(論文リファレンス [Wag02])を使って署名を偽造して善人者のお金を盗める。 攻撃にかかる時間計算量オーダーはO(22√k) kは巡回群Gの位数pのbit長 ランダム値 ri の使い回しは厳禁 集約鍵の生成過程で、他の署名者に秘密鍵が暴かれてしまいます
- 30. ビットコインへの適用
- 32. non black-box 相互的集約署 名 しかし、簡素公開鍵モデル上でのblackbox 相互的集 約署名はうまくいかない Appendix Aでこれを証明 このため、本論文では簡素公開鍵モデル上でのnon black-box 相互的集約署名を提案 ただし、具体的な提案内容はなし
- 35. fin.