public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Watson Ladd <watsonbladd@gmail•com>
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 15:57:06 -0500	[thread overview]
Message-ID: <20170225205706.GA16059@savin.petertodd.org> (raw)
In-Reply-To: <CACsn0ckikbifubOMoZphHcreXHzg=ELcPhOD02VhD-J8-MyaBA@mail.gmail.com>

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

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. 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.
> 
> 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 such
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 segwit
does.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2017-02-25 20:57 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 ` 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 [this message]
2017-02-25 20:53             ` Russell O'Connor
2017-02-25 21:04               ` Peter Todd
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=20170225205706.GA16059@savin.petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=steven.charles.davis@gmail$(echo .)com \
    --cc=watsonbladd@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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