From: Peter Todd <pete@petertodd.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
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
Date: Sat, 25 Feb 2017 16:04:06 -0500 [thread overview]
Message-ID: <20170225210406.GA16196@savin.petertodd.org> (raw)
In-Reply-To: <CAMZUoK=sq_sRoXuySca-VAGwA3AzeoZ5iNFSnKULbj+NtPjHFA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
On Sat, Feb 25, 2017 at 03:53:12PM -0500, Russell O'Connor wrote:
> 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
I'm very aware of that, in fact I think I may have even been the first person
to post on this list the commit-reveal mitigation.
Note how I said earlier in the message you're replying to that "P2SH's 160-bits
is insufficient in certain use-cases such as multisig"
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-02-25 21:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.22137.1487974823.31141.bitcoin-dev@lists.linuxfoundation.org>
2017-02-24 23:49 ` [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers Steve Davis
2017-02-25 1:01 ` Peter Todd
2017-02-25 12:04 ` Steve Davis
2017-02-25 14:50 ` Leandro Coutinho
2017-02-25 16:10 ` Ethan Heilman
2017-02-25 17:45 ` Shin'ichiro Matsuo
2017-02-27 9:15 ` Henning Kopp
2017-02-25 18:19 ` Alice Wonder
2017-02-25 18:36 ` Ethan Heilman
2017-02-25 19:12 ` Peter Todd
2017-02-25 20:42 ` Watson Ladd
2017-02-25 20:57 ` Peter Todd
2017-02-25 20:53 ` Russell O'Connor
2017-02-25 21:04 ` Peter Todd [this message]
2017-02-25 21:21 ` Dave Scotese
2017-02-25 21:34 ` Steve Davis
2017-02-25 21:40 ` Peter Todd
2017-02-25 21:54 ` Steve Davis
2017-02-25 22:14 ` Pieter Wuille
2017-02-25 22:34 ` Ethan Heilman
2017-02-26 6:26 ` Steve Davis
2017-02-26 6:36 ` Pieter Wuille
2017-02-26 7:16 ` Steve Davis
[not found] ` <CAPg+sBirowtHqUT5GUJf9hmDEACKVX19HAon-rrz7GmO8OBsNg@mail.gmail.com>
2017-02-26 16:53 ` Steve Davis
2017-02-25 23:09 ` Leandro Coutinho
2017-02-23 18:14 Peter Todd
2017-02-23 21:28 ` Peter Todd
2017-02-23 23:57 ` Aymeric Vitte
2017-02-24 10:04 ` Tim Ruffing
2017-02-24 15:18 ` Aymeric Vitte
2017-02-24 16:30 ` Tim Ruffing
2017-02-24 17:29 ` Aymeric Vitte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170225210406.GA16196@savin.petertodd.org \
--to=pete@petertodd.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=roconnor@blockstream.io \
--cc=steven.charles.davis@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox