Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4182B6C for ; Sat, 25 Feb 2017 12:04:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B030EAC for ; Sat, 25 Feb 2017 12:04:30 +0000 (UTC) Received: by mail-it0-f54.google.com with SMTP id y135so44712704itc.1 for ; Sat, 25 Feb 2017 04:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SGF5cMv4dEVZKzb4qlpIfJW4IMgKSQAEnhem7wJftII=; b=tR4sG/zQXmEi6JT7j4tJPTcpG6oY+x8Q7i1Y0y/1JPuvEkUQhzh2M+xc6safAWlTWs TJ2C5GIejwbVmfwxxsxLE6fhQwJYJkf5Y1Lw3Y6qwHQ+74bBFprXLQieQWAOdq4KarJi SHLkVgqqx5s274kzEbtn8ZCQI0fEdLwcJ6iN4RrDk9yzKCwbaElU8+l/t/ElI5kGOKyK b8oaIB8sC8ZxFa9um7EJ4ax1Zj0lZM8BEB2Y3Rv3C+hgfYEH3Be/zTIze3B+XdfCDA89 nvRv5+wTWikhLV98OWFxbKOj+ybvgYBE0JQ09fZ8cyyULy87dfjlkWc+HwF6J3O/Ippr mDqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SGF5cMv4dEVZKzb4qlpIfJW4IMgKSQAEnhem7wJftII=; b=BZQLheWtIpIrUWCV+2HZIqRtvBa+t3A1pNq/hOAmxXCrruoF9f743qXB2gPQNLGTuf Fyps/6lVECntgR5Zw0+g2Z2XrbxbLJtd8kVc0XgDfvTEiYw58WqMROGTd7/4cXJLQGfO GTeBiDgte9XW2oRpKWb4p3/bgp2l4O1LAH/whop+FSNpC+2O08l5sDskMSELaEZQmJb6 AK5g7kqZszb8vk36JzgNAMNyASRat7kNXOv3/LHJCPaLaKpLO4qUgurW+qK6bCnKaM9g m9AigSPWE06ZWWxYJLpEpzdP3QoKMQYfQNA4ZseYgtctr5BUQd/mrFlkakTKzJ29A/+m 7QzQ== X-Gm-Message-State: AMke39naaSlIwxA2/+blyBherLhy30Yole6PNaoGECG3z38H0Qesc7p+28uTd5ZjNiNd5A== X-Received: by 10.36.17.9 with SMTP id 9mr6858260itf.84.1488024270019; Sat, 25 Feb 2017 04:04:30 -0800 (PST) Received: from [10.0.1.42] (71-81-80-204.dhcp.stls.mo.charter.com. [71.81.80.204]) by smtp.gmail.com with ESMTPSA id m202sm4314801ioe.62.2017.02.25.04.04.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Feb 2017 04:04:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Steve Davis In-Reply-To: <20170225010122.GA10233@savin.petertodd.org> Date: Sat, 25 Feb 2017 06:04:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <208F93FE-B7C8-46BE-8E00-52DBD0F43415@gmail.com> References: <8F096BE1-D305-43D4-AF10-2CC48837B14F@gmail.com> <20170225010122.GA10233@savin.petertodd.org> To: Peter Todd X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Sat, 25 Feb 2017 13:47:17 +0000 Cc: Bitcoin Protocol Discussion 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 12:04:31 -0000 > On Feb 24, 2017, at 7:01 PM, Peter Todd wrote: >=20 > On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev = wrote: >> If the 20 byte SHA1 is now considered insecure (with good reason), = what about RIPEMD-160 which is the foundation of Bitcoin addresses? >=20 > SHA1 is insecure because the SHA1 algorithm is insecure, not because = 160bits isn't enough. >=20 > AFAIK there aren't any known weaknesses in RIPEMD160, =E2=80=A6so far. I wonder how long that vacation will last? > but it also hasn't been > as closely studied as more common hash algorithms. ...but we can be sure that it will be, since the dollar value held in = existing utxos continues to increase... > That said, Bitcoin uses > RIPEMD160(SHA256(msg)), which may make creating collisions harder if = an attack > is found than if it used RIPEMD160 alone. Does that offer any greater protection? That=E2=80=99s not so clear to = me as the outputs (at least for p2pkh) only verify the public key = against the final 20 byte hash. Specifically, in the first (notional) = case the challenge would be to find a private key that has a public key = that hashes to the final hash. In the second (realistic) case, you = merely need to add the sha256 hash into the problem, which doesn=E2=80=99t= seem to me to increase the difficulty by any significant amount?=20 /s=