Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
高速で安全な2者間のECDSA署名
Search
shigeyuki azuchi
December 04, 2018
Technology
230
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
高速で安全な2者間のECDSA署名
GBEC動画解説コンテンツのスライドです。
https://goblockchain.network/2018/10/ecdsa_2-of-2_multisig/
shigeyuki azuchi
December 04, 2018
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
SLH-DSA (SPHINCS+)
azuchi
0
8
Hyper Tree
azuchi
0
18
FORS
azuchi
0
30
クラスターmempool
azuchi
0
42
W-OTS+
azuchi
0
49
Shorのアルゴリズム
azuchi
0
71
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
55
Fiat-Shamir変換と注意点
azuchi
0
260
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
69
Other Decks in Technology
See All in Technology
Deployment の 先にある AI Agent 基盤 - kagent vNext、Agent Substrate、Hermes から読み解く Agent Runtime の現在地 / k8s-matsuri-2-ai-agent-platform-amsy810
masayaaoyama
3
570
synctest時代のhttptest Go 1.27で変わるHTTPサーバテストの裏側 / go conference2026 synctest and httptest
budougumi0617
1
3k
Spring BootからQuarkusへの移行
tatsuya1bm
2
120
研究開発部の紹介 / Sansan R&D Profile
sansan33
PRO
5
25k
20260912_スクフェス三河
kgnkhkr
0
380
アクセスキーこわい やめかたと漏らさない工夫
sassssan68
1
260
AIを活用するために決めた "やらないこと" - 価値に注目する / Not betting on AI
soudai
PRO
1
530
AI に書かせたその API、 “信頼” できますか?
nagix
0
110
LLMに渡さなかった仕事
nanaism
0
170
越境するなら専門用語を使うな高校校歌 / If you wanna cross border, you shouldn't use jargon
vtryo
0
140
ソフトウェアDNAとクラウドエージェントのススメ
cloudace
0
110
iOSDC Japan 2026 day1 TrackC 10:50
feedtailor
1
160
Featured
See All Featured
Are puppies a ranking factor?
jonoalderson
2
3.9k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
430
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
2.9k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.3k
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
690
Code Reviewing Like a Champion
maltzj
528
40k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
460
The untapped power of vector embeddings
frankvandijk
2
1.9k
Design in an AI World
tapps
1
320
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
280
sira's awesome portfolio website redesign presentation
elsirapls
0
410
Transcript
高速で安全な2者間のECDSA署名
1 Bitcoinの通常の2-of-2マルチシグ Bitcoinを使用する際に複数個の署名を必要とする仕組み 2人の署名があればBitcoinを使用できる アリス ボブ 2 <アリスの公開鍵> <ボブの公開鍵> 2 CHECKMULTISIG 2-of-2のマルチシグスクリプト scriptPubKey 0 <アリスの署名> <ボブの署名>
scriptSig
2 ECDSA Signature • 秘密鍵: x • 公開鍵: P =
xG • メッセージ: m • ハッシュ関数: H() 【署名の生成】 1. ランダムなnonce k を選択。 2. kを秘密鍵とした楕円曲線上の点 R = kGを計算。 3. 点Rのx座標をrとする。 4. を計算 5. 生成した (r, s)がECDSAの署名データ。 【署名の検証】
3 Yehuda Lindellのペーパー
4 ECDSAでマルチシグを構成するポイント 署名(r, s)の内、秘密鍵を使った計算をするのはsの計算↓ 秘密鍵xを2者の秘密鍵から計算する値にすると、署名は単 一だが、有効な署名を生成するためには2者の秘密鍵を必 要とするマルチシグを構成することができる。 x = アリスの秘密鍵
× ボブの秘密鍵 ※両者がお互い自分の秘密鍵を明らかにすることなく sを計算できる必要がある
鍵ペア P1 = x1G nonce R1 = k1G 5 コインのロック
Pにロックされたコインをアンロックするすためには が計算できればいい 鍵ペア P2 = x2G nonce R2 = k2G P1, R1, P2, R2を共有 P = x1 ・ P2 を計算 R = k1 ・R2 を計算 P = x2 ・ P1 を計算 R = k2 ・R1 を計算 計算した点Pと点Rはそれぞれ同じ点になる P宛にコインを送金するとマルチシグへのロックとなる
6 秘密計算で署名データを計算 ①アリスは、Paillier暗号用の鍵ペアを生成(priv, pub) ※Paillier暗号は加法準同型性がある暗号スキーム ②pubを使ってアリスの秘密鍵x1を暗号化Enc(x1)し、 pubと一緒にボブに送信 Enc(x1) pub ③
ボブは、以下の計算をしてpubで暗号化 Enc(x1)を使って以下を計算 c3 = c1⊕c2を計算して、アリスに送る。 ④ アリスはc3を復号して s’ を計算 ⑤ s’にk1^-1を掛けるとアンロックに必要な署名値 s が手に入る 両者ともに秘密鍵 x1, x2を明らかにすることなく、 マルチシグのアンロックに必要な署名値を計算できる 1
7 ECDSAベースのマルチシグのメリット • プライバシーの向上 ロックスクリプトも通常のP2PKHやP2WPKHのように単一の公開鍵への ロックとなるため、マルチシグを利用したコントラクトであることは当事者 以外分からない。 • データサイズの削減 通常のマルチシグの場合、1つの署名データにつき73バイトのデータを
必要とするが、Lindellのマルチシグでは単一の署名データになるため、 その分トランザクションサイズが削減され、ブロックチェーンのスペースも 削減できる。 • さまざまなコントラクトへの適用 Lightning Network(Multi-Hop Locks)やAdaptor Signatureを利用した Atomic SwapなどScriptlessなコントラクトに(Schnorrを待たずとも) 今すぐ適用可能。