From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0261C305 for ; Sat, 25 Feb 2017 20:53:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67D861A7 for ; Sat, 25 Feb 2017 20:53:34 +0000 (UTC) Received: by mail-ua0-f175.google.com with SMTP id 72so7855653uaf.3 for ; Sat, 25 Feb 2017 12:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0rbWjOGwN8Wl88w0AkpsZMbUtLxEF3FltpD6/bIlt0Y=; b=uWFc6YH8jYg+SFkZAPp5wT8p74xj+kpW4i9/bfcV2/V4CFRjeTEKCOL6rfIesU46y/ z6FgJ+kniPhodloRLMZ19zNdtdqyZ88nvcOK6vJyIh7gguGSMgQsQwt0poYSvFJktgSB M6T338ozsEFh1O0khTa02yqRt3g2jJk6HkfCX6HTogRj3YPTv5YLQj4YPcLf5RaaJNXx dAVeDRBhBHvRm50hvWQVmadmfBTmsZ+UDfz7OemnmMfkJGOToqUcISbLnzrjmyEeelRS x4GxphuN6ajuTLIzo6vERtXjR/RkbfeqR6ety8l9KO6E1/3LpRilVol4BCQdUsVe5z2k 6wZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0rbWjOGwN8Wl88w0AkpsZMbUtLxEF3FltpD6/bIlt0Y=; b=qNVy6zpa2XxDq8ejFmD9DkhBZqTcT+X+WW4XuhPHiQjnse28yZyf4+NfLQH7KXBh06 ckx2+2+C9TMjXJTlkW7XH4lCm23gP+ZopmUHYM/ZcljSl/uTVl5b+aQ8sTxCo5FpgdWg 2Lk2czRsPbmUS7e/PrXoIGivpaV5rGDvbDkz4KVvfkgeVxzq/rcv77UabOk9mWyBm3pF /S2zC88m843a6WFrUzYGcqGADhU6vSK2u61CmtX3/Z+5ArGUheO6LEIxy2t4HyqTx6nA kTw0EehkfAbXj+2IMeyhbh+tJcTfe1ZL1xL1y75Nu0/ZZ/rb4JOJf9EI0nBIh0XAsEiS y/3A== X-Gm-Message-State: AMke39k/eI8o4MowhhCoYX41K4pXLTe1WxcLI+wEc8n5LuC02VZZ12DakrxQocwA/qRZi7iR1AZN0JNXvAhPCONE X-Received: by 10.159.34.231 with SMTP id 94mr3754333uan.53.1488056013414; Sat, 25 Feb 2017 12:53:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.0.200 with HTTP; Sat, 25 Feb 2017 12:53:12 -0800 (PST) In-Reply-To: <20170225191201.GA15472@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> From: "Russell O'Connor" Date: Sat, 25 Feb 2017 15:53:12 -0500 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c03d91a1603b70549610aaa X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no 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 20:53:35 -0000 --94eb2c03d91a1603b70549610aaa Content-Type: text/plain; charset=UTF-8 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 --94eb2c03d91a1603b70549610aaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 25, 2017 at 2:12 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
O= n Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrot= e:
> >SHA1 is insecure because the SHA1 algorithm is insecure, not becau= se
> 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), colli= sions

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-case= s such
as multisig.

However, remember that a 160-bit *security level* is sufficient, and RIPEMD= 160
has 160-bit security against preimage attacks. Thus things like
pay-to-pubkey-hash are perfectly secure: sure you could generate two pubkey= s
that have the same RIPEMD160(SHA256()) digest, but if someone does that it<= br> doesn't cause the Bitcoin network itself any harm, and doing so is some= thing
you choose to do to yourself.

Be aware = that the issue is more problematic for more complex contracts.=C2=A0 For ex= ample, you are building a P2SH 2-of-2 multisig together with someone else i= f 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
=
--94eb2c03d91a1603b70549610aaa--