1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9F78FC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:25:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 655B681D68
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:25:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 655B681D68
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com
header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256
header.s=20221208 header.b=mERdnLTH
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mj2ndgrTu6DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:25:14 +0000 (UTC)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
[IPv6:2607:f8b0:4864:20::b2d])
by smtp1.osuosl.org (Postfix) with ESMTPS id 1BE7F81D70
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:25:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1BE7F81D70
Received: by mail-yb1-xb2d.google.com with SMTP id
3f1490d57ef6-ca429c9dc0bso471510276.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 07:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20221208.gappssmtp.com; s=20221208; t=1690208713; x=1690813513;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=PvXOlnK236cc/Hs8Cpo1UHiMheNLtO0BofnhJfl10cQ=;
b=mERdnLTHh6RducBjUkdgTkNGf8dKdk34Jn5H4Iwh3+azDfQlAjVlmhtZRciYeL2DwS
gqBWgVYNT1ImlvkRWgdE4LW07ciTNhv1zq7Pwnve+1lBs/XoOF425d7cMx4DANicJwuQ
mWEWE7MbH+gZddTFVjDlLrDtsBKJyFwdpk33TnsfjFYm40PIjPVqQm5SWs4CtGh53NeB
487mXkVHovQnceAt9RzuNBOJYtNvdheVW/u0CpTOFKYwAzOVAZKOc5B39HXpa4EdFl+L
hYkJgjVEVv5OP9XlPs4tyo/HjmexkoX3bITeEj8iCHrGGU2spMH7D7SO+FQ8pG3He/08
7PhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1690208713; x=1690813513;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=PvXOlnK236cc/Hs8Cpo1UHiMheNLtO0BofnhJfl10cQ=;
b=AxHZWFMiNl4JbMfiuHHUhE4HuNDqkmKjgNxbFwvAB8TtQtvOqhVt+EdIMewEeIg0VC
Qi5TcMHSoCFReeX5jydT+ILLYhVG7BLC07eEMRqbeIlCRv7BZ56D476LIpjFdnCDXDFT
4E0M37mlR3uch6moqEPhBmJF3HN1in7zSj0Z+Ff2eOiCXfBv+83mQjpkgqe9mDQryxEt
yKVQgTt47s2adbnE+7XPU3xEUWLH7AJ7N7w2LrP58mRRbsUBkiycHTkGfZufkb20dIwH
nak4jHd8e7+nxhny45rXzeGHQhIvBB/mbU4HsXrmaP3gkpci6ly+ugAuBSFa0WhZyO5A
vUfQ==
X-Gm-Message-State: ABy/qLa8OXqNuI0jWUrpRCAX0F3o+rzrI5OCuRVGdb6JDlqVuP38AnMT
rgHqbvrqKonwGVfTKvg+J0cTEHk8v8+tg34YijScFYM=
X-Google-Smtp-Source: APBJJlHMpz0zyiEDA3Ed7eba2/V9fTDL3KonW+QVDxMsfGV4hIKloHBo9Pw9X6UxG9V15zZrIwbkgrOc28f7NQPwRlE=
X-Received: by 2002:a25:db48:0:b0:d0f:6efe:e9dd with SMTP id
g69-20020a25db48000000b00d0f6efee9ddmr1432695ybf.0.1690208712674; Mon, 24 Jul
2023 07:25:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
<4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
In-Reply-To: <4kTcpBuEgsQQDiKbxOQwJ9ZCuHvWXGotb8eWGESe2wJs5e-6ke7435NyGmNfBRP17w7UoXR4c59v_6uQWRonHfvv_n545WPgt68a0cBQi-k=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 24 Jul 2023 10:25:00 -0400
Message-ID: <CAJowKg+w+P_+tWbD_Ou7kpPT9j3Xz19mDQqYLd-J5xnM17Argg@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ea5a3106013c6113"
X-Mailman-Approved-At: Mon, 24 Jul 2023 14:31:11 +0000
Cc: Tom Trevethan <tom@commerceblock.com>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jul 2023 14:25:15 -0000
--000000000000ea5a3106013c6113
Content-Type: text/plain; charset="UTF-8"
as long as all parties provide a proof of secret key along with their
public key, that should not be possible
or you can do it as a two-step process where all parties provide a
commitment to the public key and nobody reveals a public key until that
commitment is received
or if you want to be paranoid you can do both
On Mon, Jul 24, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning Tom,
>
> Would this allow party 2 to itself be composed of N >= 2 parties?
>
> MuSig2 (as opposed to MuSig1) requires that signatories provide multiple
> `R` points, not just one each, which are finally aggregated by first
> combining them using the MuSig() public key compose function.
> This prevents party 2 from creating an `R` that may allow it to perform
> certain attacks whose name escapes me right now but which I used to know.
> (it is the reason why MuSig1 requires 3 round trips, and why MuSig2
> requires at least 2 `R` nonces per signatory)
>
> Your scheme has only one `R` per party, would it not be vulnerably to that
> attack?
>
> Regards,
> ZmnSCPxj
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > We are implementing a version of 2-of-2 Schnorr Musig2 for statechains
> where the server (party 1 in the 2-of-2) will be fully 'blinded' - in that
> it can hold a private key that is required to generate an aggregate
> signature on an aggregate public key, but that it does not learn either: 1)
> The aggregate public key 2) The aggregate signature and 3) The message (m)
> being signed.
> >
> > In the model of blinded statechains, the security rests on the
> statechain server being trusted to report the NUMBER of partial signatures
> it has generated for a particular key (as opposed to being trusted to
> enforce rules on WHAT it has signed in the unblinded case) and the full set
> of signatures generated being verified client side
> https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations
> >
> > Given the 2-of-2 musig2 protocol operates as follows (in the following
> description, private keys (field elements) are denoted using lower case
> letters, and elliptic curve points as uppercase letters. G is the generator
> point and point multiplication denoted as X = xG and point addition as A =
> G + G):
> >
> > Party 1 generates private key x1 and public key X1 = x1G. Party 2
> generates private key x2 and public key X2 = x2G. The set of pubkeys is L =
> {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) = H(L,X). The
> shared (aggregate) public key X = a1X1 + a2X2 where a1 = KeyAggCoef(L,X1)
> and a2 = KeyAggCoef(L,X2).
> >
> > To sign a message m, party 1 generates nonce r1 and R1 = r1G. Party 2
> generates nonce r2 and R2 = r2G. These are aggregated into R = R1 + R2.
> >
> > Party 1 then computes 'challenge' c = H(X||R||m) and s1 = c.a1.x1 + r1
> > Party 2 then computes 'challenge' c = H(X||R||m) and s2 = c.a2.x2 + r2
> >
> > The final signature is then (R,s1+s2).
> >
> > In the case of blinding this for party 1:
> >
> > To prevent party 1 from learning of either the full public key or final
> signature seems straightforward, if party 1 doesn't not need to
> independently compute and verify c = H(X||R||m) (as they are blinded from
> the message in any case).
> >
> > 1) Key aggregation is performed only by party 2. Party 1 just sends X1
> to party 2.
> > 2) Nonce aggregation is performed only by party 2. Party 1 just sends R1
> to party 2.
> > 3) Party 2 computes c = H(X||R||m) and sends it to party 1 in order to
> compute s1 = c.a1.x1 + r1
> >
> > Party 1 never learns the final value of (R,s1+s2) or m.
> >
> > Any comments on this or potential issues would be appreciated.
> >
> > Tom
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000ea5a3106013c6113
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">as long as all parties provide a proof of secret key alon=
g with their public key, that should not be possible<div dir=3D"auto"><br><=
/div><div dir=3D"auto">or you can do it as a two-step process where all par=
ties provide a commitment to the public key and nobody reveals a public key=
until that commitment is received</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">or if you want to be paranoid you can do both</div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 2=
4, 2023, 7:00 AM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Good morning Tom,<br>
<br>
Would this allow party 2 to itself be composed of N >=3D 2 parties?<br>
<br>
MuSig2 (as opposed to MuSig1) requires that signatories provide multiple `R=
` points, not just one each, which are finally aggregated by first combinin=
g them using the MuSig() public key compose function.<br>
This prevents party 2 from creating an `R` that may allow it to perform cer=
tain attacks whose name escapes me right now but which I used to know.<br>
(it is the reason why MuSig1 requires 3 round trips, and why MuSig2 require=
s at least 2 `R` nonces per signatory)<br>
<br>
Your scheme has only one `R` per party, would it not be vulnerably to that =
attack?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Monday, July 24th, 2023 at 7:46 AM, Tom Trevethan via bitcoin-dev <<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" re=
l=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
<br>
<br>
> We are implementing a version of 2-of-2 Schnorr Musig2 for statechains=
where the server (party 1 in the 2-of-2) will be fully 'blinded' -=
in that it can hold a private key that is required to generate an aggregat=
e signature on an aggregate public key, but that it does not learn either: =
1) The aggregate public key 2) The aggregate signature and 3) The message (=
m) being signed.<br>
> <br>
> In the model of blinded statechains, the security rests on the statech=
ain server being trusted to report the NUMBER of partial signatures it has =
generated for a particular key (as opposed to being trusted to enforce rule=
s on WHAT it has signed in the unblinded case) and the full set of signatur=
es generated being verified client side <a href=3D"https://github.com/comme=
rceblock/mercury/blob/master/doc/merc_blind.md#blinding-considerations" rel=
=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/commerceblo=
ck/mercury/blob/master/doc/merc_blind.md#blinding-considerations</a><br>
> <br>
> Given the 2-of-2 musig2 protocol operates as follows (in the following=
description, private keys (field elements) are denoted using lower case le=
tters, and elliptic curve points as uppercase letters. G is the generator p=
oint and point multiplication denoted as X =3D xG and point addition as A =
=3D G + G):<br>
> <br>
> Party 1 generates private key x1 and public key X1 =3D x1G. Party 2 ge=
nerates private key x2 and public key X2 =3D x2G. The set of pubkeys is L =
=3D {X1,X2}. The key aggregation coefficient is KeyAggCoef(L,X) =3D H(L,X).=
The shared (aggregate) public key X =3D a1X1 + a2X2 where a1 =3D KeyAggCoe=
f(L,X1) and a2 =3D KeyAggCoef(L,X2).<br>
> <br>
> To sign a message m, party 1 generates nonce r1 and R1 =3D r1G. Party =
2 generates nonce r2 and R2 =3D r2G. These are aggregated into R =3D R1 + R=
2.<br>
> <br>
> Party 1 then computes 'challenge' c =3D H(X||R||m) and s1 =3D =
c.a1.x1 + r1<br>
> Party 2 then computes 'challenge' c =3D H(X||R||m) and s2 =3D =
c.a2.x2 + r2<br>
> <br>
> The final signature is then (R,s1+s2).<br>
> <br>
> In the case of blinding this for party 1:<br>
> <br>
> To prevent party 1 from learning of either the full public key or fina=
l signature seems straightforward, if party 1 doesn't not need to indep=
endently compute and verify c =3D H(X||R||m) (as they are blinded from the =
message in any case).<br>
> <br>
> 1) Key aggregation is performed only by party 2. Party 1 just sends X1=
to party 2.<br>
> 2) Nonce aggregation is performed only by party 2. Party 1 just sends =
R1 to party 2.<br>
> 3) Party 2 computes c =3D H(X||R||m) and sends it to party 1 in order =
to compute s1 =3D c.a1.x1 + r1<br>
> <br>
> Party 1 never learns the final value of (R,s1+s2) or m.<br>
> <br>
> Any comments on this or potential issues would be appreciated.<br>
> <br>
> Tom<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000ea5a3106013c6113--
|