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
|
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 6FC3B305
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Feb 2017 20:57:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148114.authsmtp.net (outmail148114.authsmtp.net
[62.13.148.114])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 978F9144
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 25 Feb 2017 20:57:10 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v1PKv8iw080312;
Sat, 25 Feb 2017 20:57:09 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 v1PKv7G7093951
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 25 Feb 2017 20:57:08 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id BC05A40123;
Sat, 25 Feb 2017 20:57:06 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 13067204AB; Sat, 25 Feb 2017 15:57:06 -0500 (EST)
Date: Sat, 25 Feb 2017 15:57:06 -0500
From: Peter Todd <pete@petertodd.org>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20170225205706.GA16059@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>
<CACsn0ckikbifubOMoZphHcreXHzg=ELcPhOD02VhD-J8-MyaBA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC"
Content-Disposition: inline
In-Reply-To: <CACsn0ckikbifubOMoZphHcreXHzg=ELcPhOD02VhD-J8-MyaBA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: f8ae1243-fb9c-11e6-bcdf-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
bgdMdAcUHlAWAgsB AmEbWVReVVp7WWs7 bghPaBtcak9QXgdq
T0pMXVMcUgQIeloG cRkeWxp7cgQIeXZx Y04sCHgKCUV4cUVg
FBxdRnAHZDJmdTJM BBZFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYB91 a1hFJlUWRUcQHzk6 XFgHFDYiVWIEW20t
MhggJ0QVFkIcelk1 eVI9RVsbOARaABw8 V11NATVVYkEIXTYq
ABgeFUgZDHVfXDxA SgclOhgABzVTXDZR BU1IUQpn
X-Authentic-SMTP: 61633532353630.1038: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 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
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:57:11 -0000
--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Feb 25, 2017 at 12:42:56PM -0800, Watson Ladd wrote:
> On Sat, Feb 25, 2017 at 11:12 AM, 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. Ass=
uming
> >> RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), colli=
sions
> >
> > That's something that we're well aware of; there have been a few discus=
sions on
> > this list about how P2SH's 160-bits is insufficient in certain use-case=
s such
> > as multisig.
> >
> > However, remember that a 160-bit *security level* is sufficient, and RI=
PEMD160
> > has 160-bit security against preimage attacks. Thus things like
> > pay-to-pubkey-hash are perfectly secure: sure you could generate two pu=
bkeys
> > 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 some=
thing
> > you choose to do to yourself.
>=20
> P2SH is not secure against collision. I could write two scripts with
> the same hash, one of which is an escrow script and the other which
> pays it to me, have someone pay to the escrow script, and then get the
> payment. Some formal analysis tools would ignore the unused
> instructions even if human analysis would not.
That's what I said: "P2SH's 160-bits is insufficient in certain use-cases s=
uch
as multisig"
Obviously any usecase where multiple people are creating a P2SH redeemScript
collaboratively is potentially vulnerable. Use-cases where the redeemScript=
was
created by a single-party however are _not_ vulnerable, as that party has
complete control over whether or not collisions are possible, by virtue of =
the
fact that they're the ones who have to make the collision happen!
Similarly, even in the multisig case, commit-reveal techniques can mitigate=
the
vulnerability, by forcing parties to commit to what pubkeys/hashlocks/etc.
they'll use for the script prior to pubkeys/hashlocks/etc. being revealed.
Though a better long-term approach is to use a 256-bit digest size, as segw=
it
does.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJYse+dAAoJECSBQD2l8JH7w64IAKqU/wWvGQoHtxTpTBSUqKtF
ErMf0GsQfUUTF7gKM7faNsypLcztD63gdMkcIa9Y8SWtIyQnSa1cY7aheLN8W+UZ
+Xeu89duX/Strp70zE0rvW9ugAZXt3R3DDXa9uJUrog5c3Z4h4A58XR8iqRqNyHb
1DBSAf0aTGN8ey2BJ/FjqTP6YcXUhzj4N0KK52PcqGhIEMSz5QDHHe8G5NPx6pOC
25RhyfZJ02NUTGUXBOe3KSsWDY5KZLUNs3aaMGTsLXd6niOJMSCReYRH+uaHGOHU
abXYQfGESAyn0Q4KYWg37Ptuj8RZ4TyLRNnDEEUS9JRghAvlHITmo4RZFJlDsJo=
=Z/OT
-----END PGP SIGNATURE-----
--wRRV7LY7NUeQGEoC--
|
