summaryrefslogtreecommitdiff
path: root/4f/e9bee3b12cd01c98f893356ae98d0288ac4bcf
blob: bb48b1480bdb4bfb2992805160aa530050f166b0 (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
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D0C42360
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Feb 2017 21:21:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com
	[209.85.220.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0ED212F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Feb 2017 21:21:57 +0000 (UTC)
Received: by mail-qk0-f196.google.com with SMTP id s186so8682324qkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Feb 2017 13:21:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=5TZ0D1/+i0jpZyeKxKCqSOpoxlPgvp4ovI5hoUDUZNM=;
	b=cCybOyrmfdIGwM/rxr0K3i6IEdEbKOU9LfKg/w7ySrBPC0mR5+ndmjwfm1fSLbXCR4
	bsBy1Ou2Qib1k8hyd6jx4IIJqKvaPiI4lXzKgK+9NbxxbL9zeyGEsgEeTHHgFNZzQLe1
	S8yMFSH563jPocSe11T9Yv3eVXpCQqdTSN1FwB2ky43bxaO4SyZLwRG/KSj+LuxjJcAY
	wbtfcJ6H1+d7SLK0Si1fF44PzAXh+DkTZxSsqkuIX2l41Ih8+DhWBopLanjWAVmvs/pl
	1545nxcDeHYDS4bnbLGD5QrY5lz7UA1wcq8xRzbZuxAzfKRFk1Rn/m3JvTVyxWcE53TO
	kK2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=5TZ0D1/+i0jpZyeKxKCqSOpoxlPgvp4ovI5hoUDUZNM=;
	b=c2P4O1k+t4Bi54YyghHEZUUpFzQg5r6pbK4O19WNC91vh+Wd/7GFpBTQgQFA6js2dr
	RDHW/sJPgpYXZfYTamX4GAQa/C27lB6tD8uWgUCyojz3GIWRMS+QGxKIIB3gao+GMAmm
	lCTajMuvwqL9VVaDRTnzYSAJAmnHB6Z9589P1PpnK0n4PsVwNGNA06KNUu1lJpLrdhsl
	o97XtFtz5G25l+7VvMZEsgnyOMx3I1CvOXz5MssvS1r6oGLDVlTk4yANbEm14wQC9qP0
	ka/Q7zJYv9ZeEq+DazI8IwPp3crpdbIhMmnFIdSa1aXVYUv9/VdSCXrGKiNdAMEAixTQ
	18mg==
X-Gm-Message-State: AMke39lo8gYkuNauo5eyhF7whm2gY61O/lc27UgaY4dbzwW5D/7aG9THnvYuz2VIxLS5SsuhTLiMpJfAI0tWqQ==
X-Received: by 10.237.59.213 with SMTP id s21mr8758697qte.146.1488057716978;
	Sat, 25 Feb 2017 13:21:56 -0800 (PST)
MIME-Version: 1.0
Sender: dscotese@gmail.com
Received: by 10.140.96.229 with HTTP; Sat, 25 Feb 2017 13:21:56 -0800 (PST)
In-Reply-To: <20170225210406.GA16196@savin.petertodd.org>
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>
From: Dave Scotese <dscotese@litmocracy.com>
Date: Sat, 25 Feb 2017 13:21:56 -0800
X-Google-Sender-Auth: rXsdVNM1L-FhbI07BaiN3L1CSbk
Message-ID: <CAGLBAhdCb+QLWRm4FWkPvaM2sU24HuafdgNiS=wgnPTGzrW05w@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1920bea0390d0549616fdb
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Steve Davis <steven.charles.davis@gmail.com>
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:21:58 -0000

--94eb2c1920bea0390d0549616fdb
Content-Type: text/plain; charset=UTF-8

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.

On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via bitcoin-dev <
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> 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/012205.html
>
> 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.
>
> 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"
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
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

--94eb2c1920bea0390d0549616fdb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">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 th=
at has the same bitcoin address if RIPEMD-160 collisions are easy, but I do=
n&#39;t see how that has any effect on anyone.=C2=A0 Maybe I&#39;m restatin=
g what Peter wrote.=C2=A0 If so, confirmation would be nice.<br></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Feb 25, 2017 a=
t 1:04 PM, Peter Todd via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div class=3D"HOEnZb"><div class=3D"h5">On Sat, Feb 25, 2017 at 03:53:1=
2PM -0500, Russell O&#39;Connor wrote:<br>
&gt; On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitco=
in-dev<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt; &gt;SHA1 is insecure because the SHA1 algorithm is insecure,=
 not because<br>
&gt; &gt; &gt; 160bits isn&#39;t enough.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I would argue that 160-bits isn&#39;t enough for collision r=
esistance.<br>
&gt; &gt; Assuming<br>
&gt; &gt; &gt; RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random orac=
le),<br>
&gt; &gt; collisions<br>
&gt; &gt;<br>
&gt; &gt; That&#39;s something that we&#39;re well aware of; there have bee=
n a few<br>
&gt; &gt; discussions on<br>
&gt; &gt; this list about how P2SH&#39;s 160-bits is insufficient in certai=
n use-cases<br>
&gt; &gt; such<br>
&gt; &gt; as multisig.<br>
&gt; &gt;<br>
&gt; &gt; However, remember that a 160-bit *security level* is sufficient, =
and<br>
&gt; &gt; RIPEMD160<br>
&gt; &gt; has 160-bit security against preimage attacks. Thus things like<b=
r>
&gt; &gt; pay-to-pubkey-hash are perfectly secure: sure you could generate =
two<br>
&gt; &gt; pubkeys<br>
&gt; &gt; that have the same RIPEMD160(SHA256()) digest, but if someone doe=
s that it<br>
&gt; &gt; doesn&#39;t cause the Bitcoin network itself any harm, and doing =
so is<br>
&gt; &gt; something<br>
&gt; &gt; you choose to do to yourself.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Be aware that the issue is more problematic for more complex contracts=
.<br>
&gt; For example, you are building a P2SH 2-of-2 multisig together with som=
eone<br>
&gt; else if you are not careful, party A can hand their key over to party =
B,<br>
&gt; who can may try to generate a collision between their second key and<b=
r>
&gt; another 2-of-2 multisig where they control both keys. See<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
6-January/012205.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2016-January/012205.html=
</a><br>
<br>
</div></div>I&#39;m very aware of that, in fact I think I may have even bee=
n the first person<br>
to post on this list the commit-reveal mitigation.<br>
<br>
Note how I said earlier in the message you&#39;re replying to that &quot;P2=
SH&#39;s 160-bits<br>
<span class=3D"im HOEnZb">is insufficient in certain use-cases such as mult=
isig&quot;<br>
<br>
</span><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">I like to p=
rovide some work at no charge to prove my value. Do you need a techie?=C2=
=A0 <br>I own <a href=3D"http://www.litmocracy.com" target=3D"_blank">Litmo=
cracy</a> and <a href=3D"http://www.memeracing.net" target=3D"_blank">Meme =
Racing</a> (in alpha). <br>I&#39;m the webmaster for <a href=3D"http://www.=
voluntaryist.com" target=3D"_blank">The Voluntaryist</a> which now accepts =
Bitcoin.<br>I also code for <a href=3D"http://dollarvigilante.com/" target=
=3D"_blank">The Dollar Vigilante</a>.<br>&quot;He ought to find it more pro=
fitable to play by the rules&quot; - Satoshi Nakamoto</div></div>
</div>

--94eb2c1920bea0390d0549616fdb--