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 16E98E8D for ; Fri, 8 Jan 2016 12:38:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 16CA5137 for ; Fri, 8 Jan 2016 12:38:52 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id sv6so216319322lbb.0 for ; Fri, 08 Jan 2016 04:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aqB7HQJZRcE525AAPeeqfklfhIPnwsowGmn7W25IsF0=; b=U8oTY5JE6sKiIvo85F0z6RMdClbZRIYvE1XfUxTVp9eGHvxvhu41Majn6AADxIgs4L pXo4YC98zjAinAEFOqxIJ0ma9d3mKGPXcZN1V9wg5Y777Msc3ZlBunBGaF5MSVHK7zDh soQponjIXyLr5H2m6tAB7CGAF58i7hLjCYKSqC0WG3g57l4W/gKe9ClhDwVZpwLQe4hs Tp6l7r+ZnfiKM33Kx0jJAjdXACPrfxEJ0OmGgsLenfY9oC+ROtJ5dBJLCi9v2Gh/l3Vk btAWjPWLODcFOgEVAd9cMsJVHBo2ZBBE4XIR2/GP+DcSAP8CbPcXBPx9Igqc+cmiQBuh RzMA== MIME-Version: 1.0 X-Received: by 10.112.201.3 with SMTP id jw3mr4460485lbc.27.1452256730586; Fri, 08 Jan 2016 04:38:50 -0800 (PST) Received: by 10.25.25.78 with HTTP; Fri, 8 Jan 2016 04:38:50 -0800 (PST) In-Reply-To: <8737u8qnye.fsf@rustcorp.com.au> References: <8760z4rbng.fsf@rustcorp.com.au> <8737u8qnye.fsf@rustcorp.com.au> Date: Fri, 8 Jan 2016 07:38:50 -0500 Message-ID: From: Gavin Andresen To: Rusty Russell Content-Type: multipart/alternative; boundary=001a11c372d48ca3a40528d1de41 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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: Fri, 08 Jan 2016 12:54:04 +0000 Cc: Rusty Russell via bitcoin-dev Subject: Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:38:53 -0000 --001a11c372d48ca3a40528d1de41 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell wrote: > Matt Corallo writes: > > Indeed, anything which uses P2SH is obviously vulnerable if there is > > an attack on RIPEMD160 which reduces it's security only marginally. > > I don't think this is true? Even if you can generate a collision in > RIPEMD160, that doesn't help you since you need to create a specific > SHA256 hash for the RIPEMD160 preimage. > > Even a preimage attack only helps if it leads to more than one preimage > fairly cheaply; that would make grinding out the SHA256 preimage easier. > AFAICT even MD4 isn't this broken. > It feels like we've gone over that before, but I can never remember where or when. I believe consensus was that if we were using the broken MD5 in all the places we use RIPEMD160 we'd still be secure today because of Satoshi's use of nested hash functions everywhere. > But just with Moore's law (doubling every 18 months), we'll worry about > economically viable attacks in 20 years.[1] > That's far enough away that I would choose simplicity, and have all SW > scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, but it's > not a no-brainer. Lets see if I've followed the specifics of the collision attack correctly, Ethan (or somebody) please let me know if I'm missing something: So attacker is in the middle of establishing a payment channel with somebody. Victim gives their public key, attacker creates the innocent fund-locking script '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is attacker's) but doesn't give it to the victim yet. Instead they then generate about 2^81scripts that are some form of pay-to-attacker .... ... wait, no that doesn't work, because SHA256 is used as the inner hash function. They'd have to generate 2^129 to find a cycle in SHA256. Instead, they .. what? I don't see a viable attack unless RIPEMD160 and SHA256 (or the combination) suffers a cryptographic break. -- -- Gavin Andresen --001a11c372d48ca3a40528d1de41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 8, 2016 at 7:02 AM, Rusty Russell <rusty@rustcorp.com.au&g= t; wrote:
Matt Co= rallo <lf-lists@mattcorallo.= com> writes:
> Indeed, anything which uses P2SH is obviously vulnerable if there is > an attack on RIPEMD160 which reduces it's security only marginally= .

I don't think this is true?=C2=A0 Even if you can generate a col= lision in
RIPEMD160, that doesn't help you since you need to create a specific SHA256 hash for the RIPEMD160 preimage.

Even a preimage attack only helps if it leads to more than one preimage
fairly cheaply; that would make grinding out the SHA256 preimage easier. AFAICT even MD4 isn't this broken.

= It feels like we've gone over that before, but I can never remember whe= re or when. I believe consensus was that if we were using the broken MD5 in= all the places we use RIPEMD160 we'd still be secure today because of = Satoshi's use of nested hash functions everywhere.

=

But just with Moore's law (doubling every 18 months), we'll worry a= bout
economically viable attacks in 20 years.[1]

That's far enough away that I would choose simplicity, and have all SW<= br> scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, b= ut it's
not a no-brainer. =C2=A0

Lets see if I'= ve followed the specifics of the collision attack correctly, Ethan (or some= body) please let me know if I'm missing something:

=
So attacker is in the middle of establishing a payment channel with so= mebody. Victim gives their public key, attacker creates the innocent fund-l= ocking script =C2=A0'2 V A 2 CHECKMULTISIG' (V is victim's publ= ic key, A is attacker's) but doesn't give it to the victim yet.

Instead they then generate about 2^81scripts that are= some form of pay-to-attacker ....
... wait, no that doesn't = work, because SHA256 is used as the inner hash function.=C2=A0 They'd h= ave to generate 2^129 to find a cycle in SHA256.

I= nstead, they .. what? I don't see a viable attack unless RIPEMD160 and = SHA256 (or the combination) suffers a cryptographic break.


--
--
Gav= in Andresen
--001a11c372d48ca3a40528d1de41--