Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7AF78EF8 for ; Fri, 8 Jan 2016 18:53:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148109.authsmtp.co.uk (outmail148109.authsmtp.co.uk [62.13.148.109]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B1E5779 for ; Fri, 8 Jan 2016 18:53:00 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt23.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u08IqwfL082446; Fri, 8 Jan 2016 18:52:58 GMT Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u08Iqunm001547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2016 18:52:57 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 9A5D041EA4; Fri, 8 Jan 2016 18:50:08 +0000 (UTC) Date: Fri, 8 Jan 2016 10:52:54 -0800 From: Peter Todd To: Rusty Russell Message-ID: <20160108185254.GA18199@muck> References: <8760z4rbng.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <8760z4rbng.fsf@rustcorp.com.au> X-Server-Quench: 086183a3-b639-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdgoUElQaAgsB AmAbWlxeVV97XGQ7 bghPaBtcak9QXgdq T0pMXVMcUQVgeF1E WEMeUhh3cwIIeX15 ZU4sXnhdXUx5JEVg EEhXHHAHZDJldWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYBhU RwxFMVVaXkERBC90 ThoFAClnTRVATSQv ZxchLlodB0cWNA07 LUcoUlEDexgIaGxY GF0aaAAA X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Cc: 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 18:53:01 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 08, 2016 at 02:00:11PM +1030, Rusty Russell via bitcoin-dev wro= te: > Pieter Wuille via bitcoin-dev > writes: > > Yes, this is what I worry about. We're constructing a 2-of-2 multisig > > escrow in a contract. I reveal my public key A, you do a 80-bit search = for > > B and C such that H(A and B) =3D H(B and C). You tell me your keys B, a= nd I > > happily send to H(A and B), which you steal with H(B and C). >=20 > FWIW, this attack would effect the current lightning-network "deployable > lightning" design at channel establishment; we reveal our pubkey in the > opening packet (which is used to redeem a P2SH using normal 2of2). >=20 > At least you need to grind before replying (which will presumably time > out), rather than being able to do it once the channel is open. >=20 > We could pre-commit by exchanging hashes of pubkeys first, but contracts > on bitcoin are hard enough to get right that I'm reluctant to add more > hoops. Note how this is a good example where trying to avoid the relatively small amount of complexity of having two different segregated witness schemes to allow for 128bit security could lead to a significant amount of upper level complexity trying to regain security. I wouldn't be surprised at all if this upper level complexity leads to exploits; at the very least it'll lead to a lot of wasted mental effort from cryptographers concerned about the potential weakness, both within and external to the Bitcoin development community. --=20 'peter'[:-1]@petertodd.org 000000000000000004aea2cfdb89c4816b7a42208dca1f3cfd66a1c9b5df4506 --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWkAWDXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNGFlYTJjZmRiODljNDgxNmI3YTQyMjA4ZGNhMWYzY2Zk NjZhMWM5YjVkZjQ1MDYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwVjAf/T0GOaaN+3wgkrzdkzOwIQewM ToFCzYovI4Lw1M3fg2vGcVzahoGAGy8ZHjK5GNsR/9mbUkiax7J8olNjkPG27HAk Q601IaOgX58clkmHEAcu8B7wMygPCz90uI0pmYpkOYEoZLLu54PG9o6+FgRmrQQU //fWi7DvLJ/bVssqltTpvhRTVkjovPUQN3e48CwG+8046vkWRDH+1vLJVvaEyXdI HvK2/PdCIj90qD7s+PtYCwn45aSA4QSW/oEOvgH/AbUeM++uCVmNI2PB8HTz8yDA Vsd1XGqOx24flIZIRKipnVQj1dTXBrZOjbF7TbVTfiGbswUidvzlpcIRudzklA== =nWmQ -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF--