From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6FC3B305 for ; 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 ; 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 To: Watson Ladd Message-ID: <20170225205706.GA16059@savin.petertodd.org> References: <8F096BE1-D305-43D4-AF10-2CC48837B14F@gmail.com> <20170225010122.GA10233@savin.petertodd.org> <208F93FE-B7C8-46BE-8E00-52DBD0F43415@gmail.com> <20170225191201.GA15472@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: 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 , Steve Davis 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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--