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
|
Return-Path: <jonasdnick@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2AF74C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:12:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EC2B96101E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:12:56 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EC2B96101E
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=V8cJYDIT
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
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 vlbvCe1Ya8UT
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:12:51 +0000 (UTC)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com
[IPv6:2a00:1450:4864:20::42f])
by smtp3.osuosl.org (Postfix) with ESMTPS id 383A560FE9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 14:12:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 383A560FE9
Received: by mail-wr1-x42f.google.com with SMTP id
ffacd0b85a97d-3163eb69487so3483593f8f.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Jul 2023 07:12:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1690207969; x=1690812769;
h=content-transfer-encoding:in-reply-to:references:to
:content-language:subject:user-agent:mime-version:date:message-id
:from:from:to:cc:subject:date:message-id:reply-to;
bh=BVGL9wolJ5kAZFuUGvbgWAt9dgMJPi6Fhf1E6dHMueQ=;
b=V8cJYDIT5D+XHQNK5sTkg3LeCnZDPLbZq9x4pwQ/UVfxv+IgKZTiIa4OQFQv0YEPOw
C5ZZrgnWYtatYI8B9++ogSPbWy1UCNdwhiSfpQJwekbU4ObJ+2XQze6FlVRYjgpnQ2E4
cCuCGW4E4+UEgrzxha2Fu1s2OlLP16baesRiepQuvRPMfLxhJFD+dQttkA/CJQgSbmWi
ySsLznnNZBObQyDCHEdtFbS7fZD5Q73m4ekXMi/CBre8tzAoA8qeCMMz69M5gt/hVXvz
ljnx/dw8Ee5RpqvXyc4PaJKNDP3gPRle+cZsiYLUV04Dwc3ftH/dT/B41qdvmwdq5o4X
lHLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1690207969; x=1690812769;
h=content-transfer-encoding:in-reply-to:references:to
:content-language:subject:user-agent:mime-version:date:message-id
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=BVGL9wolJ5kAZFuUGvbgWAt9dgMJPi6Fhf1E6dHMueQ=;
b=Bya81oiSyH17Yv9s3vfvcaMTh7gG7qD47zCbJZExsSDDWPv2JD/vB+RwX0raoR9NVA
X5Rp3Srx/DjuxhUP2PL32dbMkLWVFTsK0fdmR6W9emR9048xQpN8c7BFP1FdqTmw5FMN
iTQc+ly4dQgg1KK/PyLWeqszC3S1aFVuznkOV4A/obRXsMWb9kiRPAXhntl127yhvddQ
0zovwq7tbwoS0eBfE3fjui8OPPxorPPHrFPnSjPpqDRyTQXlKGvdjuCN6IP0zIJNbhL5
dkPCC4OjRcN2xQNHb46bWo0bZNequ6dAAnrq2W3O5dAk3JxYGWFeeh0OQe0x/o+wSJ2f
vxZA==
X-Gm-Message-State: ABy/qLYBOOxYLOBFryBi9CIaRMJY8JgxTdL6Ybrakud95a9MqI+DFseR
awsbxvgnfesveBVmtfDPEepn5YWGpUI=
X-Google-Smtp-Source: APBJJlGrgRVP24b95NvsXvdp4KHwIU0mjc7QE1AeXhpg4pdCZg5SCP4NbDgwkEi7Ng4xvRa3s++yxQ==
X-Received: by 2002:a5d:6b84:0:b0:317:6570:afec with SMTP id
n4-20020a5d6b84000000b003176570afecmr876913wrx.3.1690207968797;
Mon, 24 Jul 2023 07:12:48 -0700 (PDT)
Received: from [10.11.10.42] (p50879c84.dip0.t-ipconnect.de. [80.135.156.132])
by smtp.googlemail.com with ESMTPSA id
f3-20020a056000128300b0030647449730sm13205746wrx.74.2023.07.24.07.12.48
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 24 Jul 2023 07:12:48 -0700 (PDT)
From: Jonas Nick <jonasdnick@gmail.com>
X-Google-Original-From: Jonas Nick <jonasd.nick@gmail.com>
Message-ID: <ca674cee-6fe9-f325-7e09-f3efda082b6b@gmail.com>
Date: Mon, 24 Jul 2023 14:12:47 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Tom Trevethan <tom@commerceblock.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
In-Reply-To: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 24 Jul 2023 14:31:11 +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 14:12:57 -0000
Hi Tom,
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 is that
the server signs K times, but the client ends up with K+1 Schnorr signatures 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 commitment
round was skipped or if the message isn't determined before sending the nonce.
Here's how a malicious client would do that:
- Obtain K R-values R1[0], ..., R1[K-1] from the server
- Let
R[i] := R1[i] + R2[i] for all i <= K-1
R[K] := R1[0] + ... + R1[K-1]
c[i] := H(X, R[i], m[i]) for all i <= K.
Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
c[0] + ... + c[K-1] = c[K].
- Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
- Let
s[K] = s[0] + ... + s[K-1].
Then (s[K], R[K]) is a valid signature from the server, since
s[K]*G = R[K] + c[K]*a1*X1,
which the client can complete to a signature for public key X.
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 = k1*G
- Client sends c to the server and proves in zero knowledge that c =
SHA256(X1 + X2, R1 + R2, m).
- Server replies with s1 = k1 + c*x1
However, this is just some quick intuition and I'm not sure if this actually
works, but maybe worth exploring.
|
