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
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0261C305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Feb 2017 20:53:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com
[209.85.217.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67D861A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Feb 2017 20:53:34 +0000 (UTC)
Received: by mail-ua0-f175.google.com with SMTP id 72so7855653uaf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Feb 2017 12:53:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=0rbWjOGwN8Wl88w0AkpsZMbUtLxEF3FltpD6/bIlt0Y=;
b=uWFc6YH8jYg+SFkZAPp5wT8p74xj+kpW4i9/bfcV2/V4CFRjeTEKCOL6rfIesU46y/
z6FgJ+kniPhodloRLMZ19zNdtdqyZ88nvcOK6vJyIh7gguGSMgQsQwt0poYSvFJktgSB
M6T338ozsEFh1O0khTa02yqRt3g2jJk6HkfCX6HTogRj3YPTv5YLQj4YPcLf5RaaJNXx
dAVeDRBhBHvRm50hvWQVmadmfBTmsZ+UDfz7OemnmMfkJGOToqUcISbLnzrjmyEeelRS
x4GxphuN6ajuTLIzo6vERtXjR/RkbfeqR6ety8l9KO6E1/3LpRilVol4BCQdUsVe5z2k
6wZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=0rbWjOGwN8Wl88w0AkpsZMbUtLxEF3FltpD6/bIlt0Y=;
b=qNVy6zpa2XxDq8ejFmD9DkhBZqTcT+X+WW4XuhPHiQjnse28yZyf4+NfLQH7KXBh06
ckx2+2+C9TMjXJTlkW7XH4lCm23gP+ZopmUHYM/ZcljSl/uTVl5b+aQ8sTxCo5FpgdWg
2Lk2czRsPbmUS7e/PrXoIGivpaV5rGDvbDkz4KVvfkgeVxzq/rcv77UabOk9mWyBm3pF
/S2zC88m843a6WFrUzYGcqGADhU6vSK2u61CmtX3/Z+5ArGUheO6LEIxy2t4HyqTx6nA
kTw0EehkfAbXj+2IMeyhbh+tJcTfe1ZL1xL1y75Nu0/ZZ/rb4JOJf9EI0nBIh0XAsEiS
y/3A==
X-Gm-Message-State: AMke39k/eI8o4MowhhCoYX41K4pXLTe1WxcLI+wEc8n5LuC02VZZ12DakrxQocwA/qRZi7iR1AZN0JNXvAhPCONE
X-Received: by 10.159.34.231 with SMTP id 94mr3754333uan.53.1488056013414;
Sat, 25 Feb 2017 12:53:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.0.200 with HTTP; Sat, 25 Feb 2017 12:53:12 -0800 (PST)
In-Reply-To: <20170225191201.GA15472@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>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 25 Feb 2017 15:53:12 -0500
Message-ID: <CAMZUoK=sq_sRoXuySca-VAGwA3AzeoZ5iNFSnKULbj+NtPjHFA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c03d91a1603b70549610aaa
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
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 20:53:35 -0000
--94eb2c03d91a1603b70549610aaa
Content-Type: text/plain; charset=UTF-8
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
--94eb2c03d91a1603b70549610aaa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">O=
n Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrot=
e:<br>
> >SHA1 is insecure because the SHA1 algorithm is insecure, not becau=
se<br>
> 160bits isn't enough.<br>
><br>
> I would argue that 160-bits isn't enough for collision resistance.=
Assuming<br>
> RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), colli=
sions<br>
<br>
</span>That's something that we're well aware of; there have been a=
few discussions on<br>
this list about how P2SH's 160-bits is insufficient in certain use-case=
s such<br>
as multisig.<br>
<br>
However, remember that a 160-bit *security level* is sufficient, and RIPEMD=
160<br>
has 160-bit security against preimage attacks. Thus things like<br>
pay-to-pubkey-hash are perfectly secure: sure you could generate two pubkey=
s<br>
that have the same RIPEMD160(SHA256()) digest, but if someone does that it<=
br>
doesn't cause the Bitcoin network itself any harm, and doing so is some=
thing<br>
you choose to do to yourself.<br></blockquote><div><br></div><div>Be aware =
that the issue is more problematic for more complex contracts.=C2=A0 For ex=
ample, you are building a P2SH 2-of-2 multisig together with someone else i=
f 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 <a href=3D"https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2016-January/012205.html">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html</a><br>=
</div></div></div></div>
--94eb2c03d91a1603b70549610aaa--
|
