Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

["Russell O'Connor" <roconnor@blockstream.io>]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2056 bytes --]