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
|
Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 78C99C002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 May 2023 04:24:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4621060E6A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 May 2023 04:24:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4621060E6A
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=ZjGLHnFW
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id p_hcpMAxn9jx
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 May 2023 04:23:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D3E7060B45
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com
[IPv6:2607:f8b0:4864:20::1133])
by smtp3.osuosl.org (Postfix) with ESMTPS id D3E7060B45
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 May 2023 04:23:58 +0000 (UTC)
Received: by mail-yw1-x1133.google.com with SMTP id
00721157ae682-55a6efe95c9so1258347b3.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Apr 2023 21:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1682915037; x=1685507037;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=R99ZCiBFme102O+6QIjVzqwajf7zaNdDRua0avdGTBs=;
b=ZjGLHnFW4f7L5d0Pg3EzQCBhaTdBGJZpM+iy2a8bWeRpXUB4JPghbOX0jsN7lvfxZT
BEWYW+doon6/42IHicOOCcAlUs4jM4LxCL1V5udMcqNMIm3F24ZEENG7lgwmcr9ueE5Q
RNoOvGYJcncDFXncjq2M4zMTkRke9+W75sr137y//XOTEqaIAN85tT+4u62Tc1XhxteO
nxEFkig+SL2BrqCQKn7w0dp68NCKRqrUgMXsRVrlwYdyrectTV9SE6biPrmdOZU0eYuB
Q+VW9SGtjvzJucuv4fovFl7tPd1B349MV1743EaL5jgZzhXiHztHoNjk4PaWU5kkZaEr
4pTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1682915037; x=1685507037;
h=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=R99ZCiBFme102O+6QIjVzqwajf7zaNdDRua0avdGTBs=;
b=IaVx6SYMpekVc/O61PCxZN52TXe33lIn3F+vJIByns1se3/xE0/ny3+z6zamc8I11Z
xPnqA6yFBnCLqwi2Z3hldIYU+8hCLSXi0fDF2nn2BtfwuMAnNnrJA4QM8W1nodBYUeOr
l7Kmm+y19YVTgIvjVQ+YADYv66aYRtrPMbpmZfLZwfvyCaN6GebUFjaq2Po1uTzYjiu7
dD44wEYxXDahtiJ7cJvWnVLq+Owh/PFINTiYxRwsUrLQSaSFYFq4yf5hOaJsTGhunIiY
y7YbtMN0QLqfzDX77wmHwkmx2AcKJKjYfPTxOQsfy5QmS30j37Sfz7Q5aPU6KF2fp8gW
ieQA==
X-Gm-Message-State: AC+VfDy6gd3geRJ8zoF/bSt6yvOyhTN2rRhzDkpw6LywondQGdYe7hRw
koY6spOm2M04CqwQtxm3SxK4YvUWZg6tJew1yRn1qvLrPHs=
X-Google-Smtp-Source: ACHHUZ50LFJPSsP1d9wMkXaBSZtpq9Rs/hGkIR3WGPtRoulIJcIvs2NfS+PfUXTeOX0ZwFU1XwZSzHwm5mY4FHSAhpk=
X-Received: by 2002:a81:8341:0:b0:559:ed1e:fc96 with SMTP id
t62-20020a818341000000b00559ed1efc96mr5498576ywf.17.1682915037472; Sun, 30
Apr 2023 21:23:57 -0700 (PDT)
MIME-Version: 1.0
References: <Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com>
In-Reply-To: <Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 1 May 2023 12:23:30 +0800
Message-ID: <CAH5Bsr28mgcLjO43pJKmk7HYKqp9m2eJ0UcGfgOS+H4sFqcTYw@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000feeb2005fa9a3072"
X-Mailman-Approved-At: Mon, 01 May 2023 08:26:46 +0000
Subject: Re: [bitcoin-dev] On adaptor security (in protocols)
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, 01 May 2023 04:24:00 -0000
--000000000000feeb2005fa9a3072
Content-Type: text/plain; charset="UTF-8"
Hi waxwing,
I think your view of the uselessness of single signer adaptors is too
pessimistic. The claim you make is that they "don't provide a way to
create enforcement that the publication of signature on a pre-defined
message will reveal a secret'' and so are useless. I think this is wrong.
If I hold a secret key for X and create a signature adaptor with some
encryption key Y with message m and do not create any further signatures
(adaptor or otherwise) on m, then any signature on m that is published
necessarily reveals the secret on Y to me. This is very useful and has
already been used for years by DLCs in production.
I haven't read the proofs in detail but I am optimistic about your
approach. One thing I was considering while reading is that you could make
a general proof against all secure Schnorr signing scheme in the ROM by
simply extending the ROM forwarding approach from Aumayer et al to all
"tweak" operations on the elements that go into the Schnorr challenge hash
i.e. the public key and the nonce. After all whether it's MuSig2, MuSig,
FROST they all must call some RO. I think we can prove that if we apply any
bijective map to the (X,R) tuple before they go into the challenge hash
function then any Schnorr-like scheme that was secure before will be secure
when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R)
is applied to it. This would be cool because then we could prove all these
variants secure for all schemes past and present in one go. I haven't got a
concrete approach but the proofs I've looked at all seem to share this
structure.
Cheers,
LL
On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi list,
> I was motivated to look more carefully at the question of the security of
> using signature adaptors after recently getting quite enthused about the
> idea of using adaptors across N signing sessions to do a kind of multiparty
> swap. But of course security analysis is also much more important for the
> base case of 2 party swapping, which is of .. some considerable practical
> importance :)
>
> There is work (referenced in Section 3 here) that's pretty substantial on
> "how secure are adaptors" (think in terms of security reductions) already
> from I guess the 2019-2021 period. But I wanted to get into scenarios of
> multiple adaptors at once or multiple signing sessions at once with the
> *same* adaptor (as mentioned above, probably this is the most important
> scenario).
>
> To be clear this is the work of an amateur and is currently unreviewed -
> hence (a) me posting it here and (b) putting the paper on github so people
> can easily add specific corrections or comments if they like:
>
> https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf
>
> I'll note that I did the analysis only around MuSig, not MuSig2.
>
> The penultimate ("third case"), that as mentioned, of "multiple signing
> sessions, same adaptor" proved to be the most interesting: in trying to
> reduce this to ECDLP I found an issue around sequencing. It may just be
> irrelevant but I'd be curious to hear what others think about that.
>
> If nothing else, I'd be very interested to hear what experts in the field
> have to say about security reductions for this primitive in the case of
> multiple concurrent signing sessions (which of course has been analyzed
> very carefully already for base MuSig(2)).
>
> Cheers,
> AdamISZ/waxwing
>
>
>
>
> Sent with Proton Mail secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000feeb2005fa9a3072
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi waxwing,</div><div><br></div><div>I think your vie=
w of the uselessness of single signer adaptors is too pessimistic. The clai=
m you make is that they "don't provide a way to create=C2=A0 enfor=
cement that the publication of signature on a pre-defined message will reve=
al a secret'' and so are useless. I think this is wrong. If I hold =
a secret key for X and create a signature adaptor with some encryption key =
Y with message m and do not create any further signatures (adaptor or other=
wise) on m, then any signature on m that is published necessarily reveals t=
he secret on Y to me. This is very useful and has already been used for yea=
rs by DLCs in production.</div><div><br></div><div>I haven't read the p=
roofs in detail but I am optimistic about your approach. One thing I was co=
nsidering while reading is that you could make a general proof against all =
secure Schnorr signing scheme in the ROM by simply extending the ROM forwar=
ding approach from Aumayer et al to all "tweak" operations on the=
elements that go into the Schnorr challenge hash i.e. the public key and t=
he nonce. After all whether it's MuSig2, MuSig, FROST they all must cal=
l some RO. I think we can prove that if we apply any bijective map to the (=
X,R) tuple before they go into the challenge hash function then any Schnorr=
-like scheme that was secure before will be secure when bip32/TR tweaking (=
i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This w=
ould be cool because then we could prove all these variants secure for all =
schemes past and present in one go. I haven't got a concrete approach b=
ut the proofs I've looked at all seem to share this structure.</div><di=
v><br></div><div>Cheers,</div><div><br></div><div>LL<br></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 30 Ap=
r 2023 at 00:20, AdamISZ via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">Hi list,<br>
I was motivated to look more carefully at the question of the security of u=
sing signature adaptors after recently getting quite enthused about the ide=
a of using adaptors across N signing sessions to do a kind of multiparty sw=
ap. But of course security analysis is also much more important for the bas=
e case of 2 party swapping, which is of .. some considerable practical impo=
rtance :)<br>
<br>
There is work (referenced in Section 3 here) that's pretty substantial =
on "how secure are adaptors" (think in terms of security reductio=
ns) already from I guess the 2019-2021 period. But I wanted to get into sce=
narios of multiple adaptors at once or multiple signing sessions at once wi=
th the *same* adaptor (as mentioned above, probably this is the most import=
ant scenario).<br>
<br>
To be clear this is the work of an amateur and is currently unreviewed - he=
nce (a) me posting it here and (b) putting the paper on github so people ca=
n easily add specific corrections or comments if they like:<br>
<br>
<a href=3D"https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptors=
ecurity.pdf" rel=3D"noreferrer" target=3D"_blank">https://github.com/AdamIS=
Z/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf</a><br>
<br>
I'll note that I did the analysis only around MuSig, not MuSig2.<br>
<br>
The penultimate ("third case"), that as mentioned, of "multi=
ple signing sessions, same adaptor" proved to be the most interesting:=
in trying to reduce this to ECDLP I found an issue around sequencing. It m=
ay just be irrelevant but I'd be curious to hear what others think abou=
t that.<br>
<br>
If nothing else, I'd be very interested to hear what experts in the fie=
ld have to say about security reductions for this primitive in the case of =
multiple concurrent signing sessions (which of course has been analyzed ver=
y carefully already for base MuSig(2)).<br>
<br>
Cheers,<br>
AdamISZ/waxwing<br>
<br>
<br>
<br>
<br>
Sent with Proton Mail secure email.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000feeb2005fa9a3072--
|