Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D0C42360 for ; Sat, 25 Feb 2017 21:21:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com [209.85.220.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0ED212F for ; Sat, 25 Feb 2017 21:21:57 +0000 (UTC) Received: by mail-qk0-f196.google.com with SMTP id s186so8682324qkb.1 for ; Sat, 25 Feb 2017 13:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5TZ0D1/+i0jpZyeKxKCqSOpoxlPgvp4ovI5hoUDUZNM=; b=cCybOyrmfdIGwM/rxr0K3i6IEdEbKOU9LfKg/w7ySrBPC0mR5+ndmjwfm1fSLbXCR4 bsBy1Ou2Qib1k8hyd6jx4IIJqKvaPiI4lXzKgK+9NbxxbL9zeyGEsgEeTHHgFNZzQLe1 S8yMFSH563jPocSe11T9Yv3eVXpCQqdTSN1FwB2ky43bxaO4SyZLwRG/KSj+LuxjJcAY wbtfcJ6H1+d7SLK0Si1fF44PzAXh+DkTZxSsqkuIX2l41Ih8+DhWBopLanjWAVmvs/pl 1545nxcDeHYDS4bnbLGD5QrY5lz7UA1wcq8xRzbZuxAzfKRFk1Rn/m3JvTVyxWcE53TO kK2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5TZ0D1/+i0jpZyeKxKCqSOpoxlPgvp4ovI5hoUDUZNM=; b=c2P4O1k+t4Bi54YyghHEZUUpFzQg5r6pbK4O19WNC91vh+Wd/7GFpBTQgQFA6js2dr RDHW/sJPgpYXZfYTamX4GAQa/C27lB6tD8uWgUCyojz3GIWRMS+QGxKIIB3gao+GMAmm lCTajMuvwqL9VVaDRTnzYSAJAmnHB6Z9589P1PpnK0n4PsVwNGNA06KNUu1lJpLrdhsl o97XtFtz5G25l+7VvMZEsgnyOMx3I1CvOXz5MssvS1r6oGLDVlTk4yANbEm14wQC9qP0 ka/Q7zJYv9ZeEq+DazI8IwPp3crpdbIhMmnFIdSa1aXVYUv9/VdSCXrGKiNdAMEAixTQ 18mg== X-Gm-Message-State: AMke39lo8gYkuNauo5eyhF7whm2gY61O/lc27UgaY4dbzwW5D/7aG9THnvYuz2VIxLS5SsuhTLiMpJfAI0tWqQ== X-Received: by 10.237.59.213 with SMTP id s21mr8758697qte.146.1488057716978; Sat, 25 Feb 2017 13:21:56 -0800 (PST) MIME-Version: 1.0 Sender: dscotese@gmail.com Received: by 10.140.96.229 with HTTP; Sat, 25 Feb 2017 13:21:56 -0800 (PST) In-Reply-To: <20170225210406.GA16196@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> <20170225210406.GA16196@savin.petertodd.org> From: Dave Scotese Date: Sat, 25 Feb 2017 13:21:56 -0800 X-Google-Sender-Auth: rXsdVNM1L-FhbI07BaiN3L1CSbk Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c1920bea0390d0549616fdb X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: 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 21:21:58 -0000 --94eb2c1920bea0390d0549616fdb Content-Type: text/plain; charset=UTF-8 I was under the impression that RIPEMD160(SHA256(msg)) is used to turn a PUBLIC key (msg) into a bitcoin address, so yeah, you could identify ANOTHER (or the same, I guess - how would you know?) public key that has the same bitcoin address if RIPEMD-160 collisions are easy, but I don't see how that has any effect on anyone. Maybe I'm restating what Peter wrote. If so, confirmation would be nice. On Sat, Feb 25, 2017 at 1:04 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --94eb2c1920bea0390d0549616fdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was under the impression that RIPEMD160(SHA256(msg)) is = used to turn a PUBLIC key (msg) into a bitcoin address, so yeah, you could = identify ANOTHER (or the same, I guess - how would you know?) public key th= at has the same bitcoin address if RIPEMD-160 collisions are easy, but I do= n't see how that has any effect on anyone.=C2=A0 Maybe I'm restatin= g what Peter wrote.=C2=A0 If so, confirmation would be nice.

On Sat, Feb 25, 2017 a= t 1:04 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
On Sat, Feb 25, 2017 at 03:53:1= 2PM -0500, Russell O'Connor wrote:
> On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@l= ists.linuxfoundation.org> wrote:
>
> > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitco= in-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 r= esistance.
> > Assuming
> > > RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random orac= le),
> > collisions
> >
> > That's something that we're well aware of; there have bee= n a few
> > discussions on
> > this list about how P2SH's 160-bits is insufficient in certai= n 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 doe= s 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 som= eone
> 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.l= inuxfoundation.org/pipermail/bitcoin-dev/2016-January/012205.html=

I'm very aware of that, in fact I think I may have even bee= n 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 "P2= SH's 160-bits
is insufficient in certain use-cases such as mult= isig"

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev




--
I like to p= rovide some work at no charge to prove my value. Do you need a techie?=C2= =A0
I own Litmo= cracy and Meme = Racing (in alpha).
I'm the webmaster for The Voluntaryist which now accepts = Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it more pro= fitable to play by the rules" - Satoshi Nakamoto
--94eb2c1920bea0390d0549616fdb--