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)
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
Precedence: list


--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--