summaryrefslogtreecommitdiff
path: root/0f/4e6d642327d2ab6a8e317498c52efae95ebe27
blob: 38084e40cc7095c6b493de290bae72ff49e28a73 (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
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
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
Return-Path: <steven.charles.davis@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C45E2305
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Feb 2017 21:34:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f68.google.com (mail-it0-f68.google.com
	[209.85.214.68])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 14BF2AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Feb 2017 21:34:36 +0000 (UTC)
Received: by mail-it0-f68.google.com with SMTP id w185so7859290ita.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Feb 2017 13:34:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
	:references; bh=muMBIhRCMvUhd7Xp5i3xMnbagGnX/sOKXjIIA4LSV3g=;
	b=P5TNdeovz9DGg0N/nmjR9CDDXRR7ItA7taambKjAKjwRXzc3PoIUOoMu6d+os9hQ2O
	14OrUyiwJ3wZ3Ckxs2Dvqo8TjjScdfNSyKehrMuwGCVB5qll/MS2q1QaiqvgjBqtWJfP
	I7CppI9tXM5AOPUaOuVKF0h+gfRF0N31GVNNx5hgM/oMRaX1uY51lHZAl4pXKvxTe0sq
	ngxliqosl0m+4uft4LN09W6HLssrYAkWN/ma2HC+GKomAWeO4D0M0Yahu2j9T8AIuzSj
	LC7OULG8VgLdKPhpx9Fd28VZ1J73kEr+gb52WesCN7KLr5DMFiu0S49CZEsrmqOf4F6D
	I4uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:message-id:mime-version:subject:date
	:in-reply-to:cc:to:references;
	bh=muMBIhRCMvUhd7Xp5i3xMnbagGnX/sOKXjIIA4LSV3g=;
	b=LquF/1/9waLBjFr2swT/nsuKgpw19LC2mC61/Ty85Q3hpNhsRuJoDkumw8GPP7bl8S
	RrcNbPeRKwrkma17uk6HI3GZd1owvXby5yadWntUGLOoYWLbSdB8bCTxv6XFd7JAuMAl
	W94HVkU6Zm2X/mTNHsoaCaCmx7aw5ipElVXa5IWIWPNS0SFDdc3bFEitbsaSAdsVmFwR
	INAMhE2NQahDPGmFFgCbJJaQhC1GiUgEDleZnmRybpATOmP0QFYUiNLy04gbwsVx/Hyc
	LQ6XIzyNhtaAi0q3U+k1ijX0NI9TlYa6WFd4e3PHVeRU1gkmTPo9FyazJf0RS4ePEbIc
	2VXA==
X-Gm-Message-State: AMke39lr37kZ6ucR0YikUGIrjdt4FtayFLoqMxb/t1+5r+fvtXCTpXQHdRZ//VeVMVDSuQ==
X-Received: by 10.36.77.149 with SMTP id l143mr7805727itb.19.1488058475368;
	Sat, 25 Feb 2017 13:34:35 -0800 (PST)
Received: from [10.0.1.42] (71-81-80-204.dhcp.stls.mo.charter.com.
	[71.81.80.204]) by smtp.gmail.com with ESMTPSA id
	c100sm2417159itd.20.2017.02.25.13.34.34
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 25 Feb 2017 13:34:34 -0800 (PST)
From: Steve Davis <steven.charles.davis@gmail.com>
Message-Id: <4FE38F6A-0560-4989-9C53-7F8C94EA4C76@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B6B7DA12-B2BF-4A3A-B194-D6BDBC112D55"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Sat, 25 Feb 2017 15:34:33 -0600
In-Reply-To: <CAGLBAhdCb+QLWRm4FWkPvaM2sU24HuafdgNiS=wgnPTGzrW05w@mail.gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
References: <mailman.22137.1487974823.31141.bitcoin-dev@lists.linuxfoundation.org>
	<8F096BE1-D305-43D4-AF10-2CC48837B14F@gmail.com>
	<20170225010122.GA10233@savin.petertodd.org>
	<208F93FE-B7C8-46BE-8E00-52DBD0F43415@gmail.com>
	<CAN6UTayzQRowtWhLKr8LyFuXjw3m+GjQGtHfkDj-Xu41Hym32w@mail.gmail.com>
	<CAEM=y+WkgSkc07ZsU6APAkcu37zVZ7dwSc=jAg1nho31S5ZyxQ@mail.gmail.com>
	<20170225191201.GA15472@savin.petertodd.org>
	<CAMZUoK=sq_sRoXuySca-VAGwA3AzeoZ5iNFSnKULbj+NtPjHFA@mail.gmail.com>
	<20170225210406.GA16196@savin.petertodd.org>
	<CAGLBAhdCb+QLWRm4FWkPvaM2sU24HuafdgNiS=wgnPTGzrW05w@mail.gmail.com>
X-Mailer: Apple Mail (2.3259)
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 25 Feb 2017 22:08:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by
 third-parties, not just repo maintainers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 25 Feb 2017 21:34:36 -0000


--Apple-Mail=_B6B7DA12-B2BF-4A3A-B194-D6BDBC112D55
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yea, well. I don=E2=80=99t think it is ethical to post instructions =
without an associated remediation (BIP) if you don=E2=80=99t see the =
potential attack.

I was rather hoping that we could have a fuller discussion of what the =
best practical response would be to such an issue?


> On Feb 25, 2017, at 3:21 PM, Dave Scotese <dscotese@litmocracy.com> =
wrote:
>=20
> I was under the impression that RIPEMD160(SHA256(msg)) is used to turn =
a PUBLIC key (msg) into a bitcoin address, so yeah, you could identify =
ANOTHER (or the same, I guess - how would you know?) public key that has =
the same bitcoin address if RIPEMD-160 collisions are easy, but I don't =
see how that has any effect on anyone.  Maybe I'm restating what Peter =
wrote.  If so, confirmation would be nice.
>=20
> On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote:
> > On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via =
bitcoin-dev
> > > wrote:
> > > > >SHA1 is insecure because the SHA1 algorithm is insecure, not =
because
> > > > 160bits isn't enough.
> > > >
> > > > I would argue that 160-bits isn't enough for collision =
resistance.
> > > Assuming
> > > > RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle),
> > > collisions
> > >
> > > That's something that we're well aware of; there have been a few
> > > discussions on
> > > this list about how P2SH's 160-bits is insufficient in certain =
use-cases
> > > such
> > > as multisig.
> > >
> > > However, remember that a 160-bit *security level* is sufficient, =
and
> > > RIPEMD160
> > > has 160-bit security against preimage attacks. Thus things like
> > > pay-to-pubkey-hash are perfectly secure: sure you could generate =
two
> > > pubkeys
> > > that have the same RIPEMD160(SHA256()) digest, but if someone does =
that it
> > > doesn't cause the Bitcoin network itself any harm, and doing so is
> > > something
> > > you choose to do to yourself.
> > >
> >
> > Be aware that the issue is more problematic for more complex =
contracts.
> > For example, you are building a P2SH 2-of-2 multisig together with =
someone
> > else if you are not careful, party A can hand their key over to =
party B,
> > who can may try to generate a collision between their second key and
> > another 2-of-2 multisig where they control both keys. See
> > =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/01220=
5.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/0122=
05.html>
>=20
> I'm very aware of that, in fact I think I may have even been the first =
person
> to post on this list the commit-reveal mitigation.
>=20
> Note how I said earlier in the message you're replying to that "P2SH's =
160-bits
> is insufficient in certain use-cases such as multisig"
>=20
> --
> https://petertodd.org <https://petertodd.org/> =
'peter'[:-1]@petertodd.org <http://petertodd.org/>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20
>=20
>=20
> --=20
> I like to provide some work at no charge to prove my value. Do you =
need a techie? =20
> I own Litmocracy <http://www.litmocracy.com/> and Meme Racing =
<http://www.memeracing.net/> (in alpha).=20
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com/> =
which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi =
Nakamoto


--Apple-Mail=_B6B7DA12-B2BF-4A3A-B194-D6BDBC112D55
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Yea, well. I don=E2=80=99t think it is ethical to post =
instructions without an associated remediation (BIP) if you don=E2=80=99t =
see the potential attack.<div class=3D""><br class=3D""></div><div =
class=3D"">I was rather hoping that we could have a fuller discussion of =
what the best practical response would be to such an issue?<br =
class=3D""><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Feb 25, 2017, at 3:21 PM, Dave Scotese &lt;<a =
href=3D"mailto:dscotese@litmocracy.com" =
class=3D"">dscotese@litmocracy.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">I was under the impression that RIPEMD160(SHA256(msg)) is =
used to turn a PUBLIC key (msg) into a bitcoin address, so yeah, you =
could identify ANOTHER (or the same, I guess - how would you know?) =
public key that has the same bitcoin address if RIPEMD-160 collisions =
are easy, but I don't see how that has any effect on anyone.&nbsp; Maybe =
I'm restating what Peter wrote.&nbsp; If so, confirmation would be =
nice.<br class=3D""></div><div class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via =
bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
class=3D"HOEnZb"><div class=3D"h5">On Sat, Feb 25, 2017 at 03:53:12PM =
-0500, Russell O'Connor wrote:<br class=3D"">
&gt; On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev &lt;<br =
class=3D"">
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>&gt; =
wrote:<br class=3D"">
&gt;<br class=3D"">
&gt; &gt; On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via =
bitcoin-dev<br class=3D"">
&gt; &gt; wrote:<br class=3D"">
&gt; &gt; &gt; &gt;SHA1 is insecure because the SHA1 algorithm is =
insecure, not because<br class=3D"">
&gt; &gt; &gt; 160bits isn't enough.<br class=3D"">
&gt; &gt; &gt;<br class=3D"">
&gt; &gt; &gt; I would argue that 160-bits isn't enough for collision =
resistance.<br class=3D"">
&gt; &gt; Assuming<br class=3D"">
&gt; &gt; &gt; RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random =
oracle),<br class=3D"">
&gt; &gt; collisions<br class=3D"">
&gt; &gt;<br class=3D"">
&gt; &gt; That's something that we're well aware of; there have been a =
few<br class=3D"">
&gt; &gt; discussions on<br class=3D"">
&gt; &gt; this list about how P2SH's 160-bits is insufficient in certain =
use-cases<br class=3D"">
&gt; &gt; such<br class=3D"">
&gt; &gt; as multisig.<br class=3D"">
&gt; &gt;<br class=3D"">
&gt; &gt; However, remember that a 160-bit *security level* is =
sufficient, and<br class=3D"">
&gt; &gt; RIPEMD160<br class=3D"">
&gt; &gt; has 160-bit security against preimage attacks. Thus things =
like<br class=3D"">
&gt; &gt; pay-to-pubkey-hash are perfectly secure: sure you could =
generate two<br class=3D"">
&gt; &gt; pubkeys<br class=3D"">
&gt; &gt; that have the same RIPEMD160(SHA256()) digest, but if someone =
does that it<br class=3D"">
&gt; &gt; doesn't cause the Bitcoin network itself any harm, and doing =
so is<br class=3D"">
&gt; &gt; something<br class=3D"">
&gt; &gt; you choose to do to yourself.<br class=3D"">
&gt; &gt;<br class=3D"">
&gt;<br class=3D"">
&gt; Be aware that the issue is more problematic for more complex =
contracts.<br class=3D"">
&gt; For example, you are building a P2SH 2-of-2 multisig together with =
someone<br class=3D"">
&gt; else if you are not careful, party A can hand their key over to =
party B,<br class=3D"">
&gt; who can may try to generate a collision between their second key =
and<br class=3D"">
&gt; another 2-of-2 multisig where they control both keys. See<br =
class=3D"">
&gt; <a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Janua=
ry/012205.html" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/pipermail/bitcoin-dev/<wbr =
class=3D"">2016-January/012205.html</a><br class=3D"">
<br class=3D"">
</div></div>I'm very aware of that, in fact I think I may have even been =
the first person<br class=3D"">
to post on this list the commit-reveal mitigation.<br class=3D"">
<br class=3D"">
Note how I said earlier in the message you're replying to that "P2SH's =
160-bits<br class=3D"">
<span class=3D"im HOEnZb">is insufficient in certain use-cases such as =
multisig"<br class=3D"">
<br class=3D"">
</span><div class=3D"HOEnZb"><div class=3D"h5">--<br class=3D"">
<a href=3D"https://petertodd.org/" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://petertodd.org</a> 'peter'[:-1]@<a =
href=3D"http://petertodd.org/" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">petertodd.org</a><br class=3D"">
</div></div><br class=3D"">______________________________<wbr =
class=3D"">_________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br =
class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.<wbr =
class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br =
class=3D"">
<br class=3D""></blockquote></div><br class=3D""><br clear=3D"all" =
class=3D""><br class=3D"">-- <br class=3D""><div class=3D"gmail_signature"=
 data-smartmail=3D"gmail_signature"><div dir=3D"ltr" class=3D"">I like =
to provide some work at no charge to prove my value. Do you need a =
techie?&nbsp; <br class=3D"">I own <a href=3D"http://www.litmocracy.com/" =
target=3D"_blank" class=3D"">Litmocracy</a> and <a =
href=3D"http://www.memeracing.net/" target=3D"_blank" class=3D"">Meme =
Racing</a> (in alpha). <br class=3D"">I'm the webmaster for <a =
href=3D"http://www.voluntaryist.com/" target=3D"_blank" class=3D"">The =
Voluntaryist</a> which now accepts Bitcoin.<br class=3D"">I also code =
for <a href=3D"http://dollarvigilante.com/" target=3D"_blank" =
class=3D"">The Dollar Vigilante</a>.<br class=3D"">"He ought to find it =
more profitable to play by the rules" - Satoshi Nakamoto</div></div>
</div>
</div></blockquote></div><br class=3D""></div></div></body></html>=

--Apple-Mail=_B6B7DA12-B2BF-4A3A-B194-D6BDBC112D55--