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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7AF78EF8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 18:53:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148109.authsmtp.co.uk (outmail148109.authsmtp.co.uk
[62.13.148.109])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id B1E5779
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jan 2016 18:53:00 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u08IqwfL082446;
Fri, 8 Jan 2016 18:52:58 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u08Iqunm001547
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 8 Jan 2016 18:52:57 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 9A5D041EA4;
Fri, 8 Jan 2016 18:50:08 +0000 (UTC)
Date: Fri, 8 Jan 2016 10:52:54 -0800
From: Peter Todd <pete@petertodd.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Message-ID: <20160108185254.GA18199@muck>
References: <CABsx9T3aTme2EQATamGGzeqNqJkUcPGa=0LVidJSRYNznM-myQ@mail.gmail.com>
<CAPg+sBhH0MODjjp8Avx+Fy_UGqzMjUq_jn3vT3oH=u3711tsSA@mail.gmail.com>
<8760z4rbng.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF"
Content-Disposition: inline
In-Reply-To: <8760z4rbng.fsf@rustcorp.com.au>
X-Server-Quench: 086183a3-b639-11e5-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdgoUElQaAgsB AmAbWlxeVV97XGQ7 bghPaBtcak9QXgdq
T0pMXVMcUQVgeF1E WEMeUhh3cwIIeX15 ZU4sXnhdXUx5JEVg
EEhXHHAHZDJldWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
FAgyOXU9MCtqYBhU RwxFMVVaXkERBC90 ThoFAClnTRVATSQv
ZxchLlodB0cWNA07 LUcoUlEDexgIaGxY GF0aaAAA
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks
or not?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 08 Jan 2016 18:53:01 -0000
--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 08, 2016 at 02:00:11PM +1030, Rusty Russell via bitcoin-dev wro=
te:
> Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > Yes, this is what I worry about. We're constructing a 2-of-2 multisig
> > escrow in a contract. I reveal my public key A, you do a 80-bit search =
for
> > B and C such that H(A and B) =3D H(B and C). You tell me your keys B, a=
nd I
> > happily send to H(A and B), which you steal with H(B and C).
>=20
> FWIW, this attack would effect the current lightning-network "deployable
> lightning" design at channel establishment; we reveal our pubkey in the
> opening packet (which is used to redeem a P2SH using normal 2of2).
>=20
> At least you need to grind before replying (which will presumably time
> out), rather than being able to do it once the channel is open.
>=20
> We could pre-commit by exchanging hashes of pubkeys first, but contracts
> on bitcoin are hard enough to get right that I'm reluctant to add more
> hoops.
Note how this is a good example where trying to avoid the relatively
small amount of complexity of having two different segregated witness
schemes to allow for 128bit security could lead to a significant amount
of upper level complexity trying to regain security. I wouldn't be
surprised at all if this upper level complexity leads to exploits; at
the very least it'll lead to a lot of wasted mental effort from
cryptographers concerned about the potential weakness, both within and
external to the Bitcoin development community.
--=20
'peter'[:-1]@petertodd.org
000000000000000004aea2cfdb89c4816b7a42208dca1f3cfd66a1c9b5df4506
--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWkAWDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNGFlYTJjZmRiODljNDgxNmI3YTQyMjA4ZGNhMWYzY2Zk
NjZhMWM5YjVkZjQ1MDYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwVjAf/T0GOaaN+3wgkrzdkzOwIQewM
ToFCzYovI4Lw1M3fg2vGcVzahoGAGy8ZHjK5GNsR/9mbUkiax7J8olNjkPG27HAk
Q601IaOgX58clkmHEAcu8B7wMygPCz90uI0pmYpkOYEoZLLu54PG9o6+FgRmrQQU
//fWi7DvLJ/bVssqltTpvhRTVkjovPUQN3e48CwG+8046vkWRDH+1vLJVvaEyXdI
HvK2/PdCIj90qD7s+PtYCwn45aSA4QSW/oEOvgH/AbUeM++uCVmNI2PB8HTz8yDA
Vsd1XGqOx24flIZIRKipnVQj1dTXBrZOjbF7TbVTfiGbswUidvzlpcIRudzklA==
=nWmQ
-----END PGP SIGNATURE-----
--h31gzZEtNLTqOjlF--
|
