summaryrefslogtreecommitdiff
path: root/08/713b23ed8fb7b157cc53685cfd89799bda13d3
blob: c40030ba8a6fcdf7ccd755ac58554ea000fa3e76 (plain)
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
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DC3CAC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 17:00:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A891C416D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 17:00:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org A891C416D3
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=MF7A061w
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zcPndbrTHy81
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 17:00:30 +0000 (UTC)
X-Greylist: delayed 504 seconds by postgrey-1.37 at util1.osuosl.org;
 Mon, 24 Jul 2023 17:00:30 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 20606416CD
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
 [185.70.41.103])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 20606416CD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Jul 2023 17:00:29 +0000 (UTC)
Date: Mon, 24 Jul 2023 16:51:44 +0000
Authentication-Results: mail-41103.protonmail.ch;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.b="MF7A061w"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1690217514; x=1690476714;
 bh=R4j6LM84QpUFiCC6f63g1BRaGbNCjicwbAbHbKdmwIA=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=MF7A061wOBrH1hQxLCxYlsUc4QZdjtXi353sU7yLgZqLKO+xfQxsCU7l3+hFQbV+u
 g6FEp/Iiaq2wClur9WzPLVBGaUrqxGVhMJdGp26bwfbUZio5MHU+rrCkeFqaEp95Cq
 My1iGT0tgfEEr3iODOVrjyUuyYpcWm+16/16XA0y5LTp/0DktzUccVXH3MFa+LqynD
 Jwg5MGU9g7pGjSlKI8ywMe8+9vPaFP4c5zrY5uwyOj+N+Desod2Duk4FcuYawGRI4m
 agcUDrKUmMawTKgly3n6Xe1pOnwR4WClQ4uaWX3jwwMNhREUTRH65geBO7tZUrQCoY
 SjXqF1W+5M4Tg==
To: Tom Trevethan <tom@commerceblock.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <YwMiFAEImHAJfAHHU7WbN1C1JuHjh0vC18Hn61QplFOlY5mEgKmjsAlj2geV1-28E36_wgfL9_QHTRJsbtOLt73o9C4JfoVt8scvYGzKHOI=@protonmail.com>
In-Reply-To: <ca674cee-6fe9-f325-7e09-f3efda082b6b@gmail.com>
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <ca674cee-6fe9-f325-7e09-f3efda082b6b@gmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 24 Jul 2023 17:59:17 +0000
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 17:00:32 -0000

@ZmnSCPxj:

yes, Wagner is the attack you were thinking of.

And yeah, to avoid it, you should have the 3rd round of MuSig1, i.e. the R =
commitments.

@Tom:
As per above it seems you were more considering MuSig1 here, not MuSig2. At=
 least in this version. So you need the initial commitments to R.

Jonas' reply clearly has covered a lot of what matters here, but I wanted t=
o mention (using your notation):

in s1 =3D c * a1 * x1 + r1, you expressed the idea that the challenge c cou=
ld be given to the server, to construct s1, but since a1 =3D H(L, X1) and L=
 is the serialization of all (in this case, 2) keys, that wouldn't work for=
 blinding the final key, right?
But, is it possible that this addresses the other problem?
If the server is given c1*a1 instead as the challenge for signing (with the=
ir "pure" key x1), then perhaps it avoids the issue? Given what's on the bl=
ockchain ends up allowing calculation of 'c' and the aggregate key a1X1 + a=
2X2, is it the case that you cannot find a1 and therefore you cannot correl=
ate the transaction with just the quantity 'c1*a1' which the server sees?

But I agree with Jonas that this is just the start, i.e. the fundamental re=
quirement of a blind signing scheme is there has to be some guarantee of no=
 'one more forgery' possibility, so presumably there has to be some proof t=
hat the signing request is 'well formed' (Jonas expresses it below as a ZKP=
 of a SHA2 preimage .. it does not seem pretty but I agree that on the face=
 of it, that is what's needed).

@Jonas, Erik:
'posk' is probably meant as 'proof of secret key' which may(?) be a mixup w=
ith what is sometimes referred to in the literature as "KOSK" (iirc they us=
ed it in FROST for example). It isn't clear to me yet how that factors into=
 this scenario, although ofc it is for sure a potential building block of t=
hese constructions.

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, July 24th, 2023 at 08:12, Jonas Nick via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:


> Hi Tom,
>=20
> I'm not convinced that this works. As far as I know blind musig is still =
an open
> research problem. What the scheme you propose appears to try to prevent i=
s that
> the server signs K times, but the client ends up with K+1 Schnorr signatu=
res for
> the aggregate of the server's and the clients key. I think it's possible =
to
> apply a variant of the attack that makes MuSig1 insecure if the nonce com=
mitment
> round was skipped or if the message isn't determined before sending the n=
once.
> Here's how a malicious client would do that:
>=20
> - Obtain K R-values R1[0], ..., R1[K-1] from the server
> - Let
> R[i] :=3D R1[i] + R2[i] for all i <=3D K-1
> R[K] :=3D R1[0] + ... + R1[K-1]
> c[i] :=3D H(X, R[i], m[i]) for all i <=3D K.
> Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
> c[0] + ... + c[K-1] =3D c[K].
> - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
> - Let
> s[K] =3D s[0] + ... + s[K-1].
> Then (s[K], R[K]) is a valid signature from the server, since
> s[K]G =3D R[K] + c[K]a1X1,
> which the client can complete to a signature for public key X.
>=20
> What may work in your case is the following scheme:
> - Client sends commitment to the public key X2, nonce R2 and message m to=
 the
> server.
> - Server replies with nonce R1 =3D k1G
> - Client sends c to the server and proves in zero knowledge that c =3D
> SHA256(X1 + X2, R1 + R2, m).
> - Server replies with s1 =3D k1 + c*x1
>=20
> However, this is just some quick intuition and I'm not sure if this actua=
lly
> works, but maybe worth exploring.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev