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
|
Return-Path: <crypto@timruffing.de>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id A23CCC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 16:56:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 8CC2F203F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 16:56:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iwMq03zoFTgJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 16:56:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171])
by silver.osuosl.org (Postfix) with ESMTPS id 9D5DD2039D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Feb 2020 16:56:16 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
(using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits))
(No client certificate requested)
by mout-p-201.mailbox.org (Postfix) with ESMTPS id 48R7W20t1rzQlMX;
Mon, 24 Feb 2020 17:56:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241])
by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173])
(amavisd-new, port 10030)
with ESMTP id dAf__uxmcX5n; Mon, 24 Feb 2020 17:56:07 +0100 (CET)
Message-ID: <434552b61a8116f0f7c8cf0e217c582cad871449.camel@timruffing.de>
From: Tim Ruffing <crypto@timruffing.de>
To: Erik Aronesty <erik@q32.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 24 Feb 2020 17:56:06 +0100
In-Reply-To: <CAJowKgJSaDUGM-X7U-eaaCSCSr6x0s+Z5U=Tt3Bt4J1D7SSnnA@mail.gmail.com>
References: <u1IeyK5A7zyklXzl26UpCliJrFEsDp5SXUGbtXGBCrEWw6Wi7vNcoy4HNv2WXUTG_SBuMURDLhvh3YCwL2r53rL0Yj19TZpumYFD5WqmYL8=@protonmail.com>
<CAJowKgJP7FgF1KWOg4Wn=D4CjBgoE-ZYXv8LnfbVfh62ZNG5kQ@mail.gmail.com>
<30bdd65dc943f698c0970ca51bfb4dfb406ea7b8.camel@timruffing.de>
<CAJowKgJSaDUGM-X7U-eaaCSCSr6x0s+Z5U=Tt3Bt4J1D7SSnnA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 24 Feb 2020 16:59:03 +0000
Subject: Re: [bitcoin-dev] Composable MuSig
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 Feb 2020 16:56:18 -0000
The only thing that matters is the number of parallel sessions. If you
bound this to something like 2 or 3, then the resulting scheme may be
secure. But you need to the actual math of Wagner's attack, and who
knows how efficient it can be implemented in practice.
Timeouts on top of this won't help. And who needs 2 or 3 parallel
sessions? If you need parallel sessions (or not), use 3-round MuSig and
the entire issue is simply eliminated.
Tim
On Mon, 2020-02-24 at 10:30 -0500, Erik Aronesty wrote:
> Basically just some mechanism for preventing repeated signings of the
> same message, and using a "validity" time window so that the amount
> of
> state you need to enquire about isn't unbounded.
>
> The Drijvers, et al paper is specifically concerned with parallel and
> aborted signings, where ksums can be used. In general, the more
> variables that an attacker can control ,the more "k" lists they can
> form, and the more likely they can find collisions.
>
> If signers refused to sign "stale" messages, refused to sign in
> parallel beyond a certain limit, and refused to sign the same message
> twice, it should help reduce the attack surface.
>
> On Mon, Feb 24, 2020 at 6:41 AM Tim Ruffing via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Sun, 2020-02-23 at 02:27 -0500, Erik Aronesty via bitcoin-dev
> > wrote:
> > > > Thus, two-phase MuSig is potentially unsafe.
> > > > https://eprint.iacr.org/2018/417.pdf describes the argument.
> > >
> > > One solution is to add a signature timeout to the message (say a
> > > block height) .
> > >
> > > A participant refuses to sign if that time is too far in the
> > > future,
> > > or is at all in the past, or if a message M is the same as any
> > > previous message within that time window.
> > >
> > > Seems to resolve the attacks on 2 round musig.
> >
> > I don't understand this. Can you elaborate?
> >
> > Best,
> > Tim
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
