Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y9on6-0001FJ-Fs for bitcoin-development@lists.sourceforge.net; Sat, 10 Jan 2015 05:40:52 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.114 as permitted sender) client-ip=62.13.148.114; envelope-from=pete@petertodd.org; helo=outmail148114.authsmtp.net; Received: from outmail148114.authsmtp.net ([62.13.148.114]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Y9on3-0001un-Sc for bitcoin-development@lists.sourceforge.net; Sat, 10 Jan 2015 05:40:52 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id t0A5ehcW079118; Sat, 10 Jan 2015 05:40:43 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0A5edkp074096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 10 Jan 2015 05:40:41 GMT Date: Sat, 10 Jan 2015 00:40:38 -0500 From: Peter Todd To: Gregory Maxwell Message-ID: <20150110054038.GA2048@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 371dd4e1-988b-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwIUElQaAgsB AmMbW1FeVF17XWE7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRxw A0tKCVlycAFGcXg+ ZERgXXEVX0N7IRJ5 F09JHGUON3phaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOSYx QSs5OX12WxVDHz17 aFR/bAZaRUVZM0M5 Nl45UE4ZORsfTm8W FEhQGyJCb1MFQCEo BgNTXEhWCjBfTCxA AxouZHdA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Y9on3-0001un-Sc Cc: Bitcoin Development Subject: Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 05:40:52 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 10, 2015 at 04:26:23AM +0000, Gregory Maxwell wrote: > The incompatibility is due to the OpenSSL update changing the > behavior of ECDSA validation to reject any signature which is > not encoded in a very rigid manner. This was a result of > OpenSSL's change for CVE-2014-8275 "Certificate fingerprints > can be modified". >=20 > While for most applications it is generally acceptable to eagerly > reject some signatures, Bitcoin is a consensus system where all > participants must generally agree on the exact validity or > invalidity of the input data. In a sense, consistency is more > important than "correctness". As an aside, it's interesting to note that this issue is not entirely unique to miners. For example in micropayment channel protocols the receiver must validate signatures from the sender to ensure that they will be able to broadcast transactions containing those signatures in the near-future. If they accept a signature as valid that the majority of hashing power rejects as invalid the sender can simply wait until the micropayment channel timeout expires to recover 100% of their funds, ripping off the receiver. There's many other advanced Bitcoin protocols with similar vulnerabilities; I'd be interested to hear if anyone can come up with a similar vulnerability in a non-Bitcoin protocol, and wouldn't be that surprised if they did. While I have often cautioned people before to avoid using libsecp256k1 for verification on the grounds that consensus trumps correctness, the above incompatibility does strongly suggest that OpenSSL may not itself have very good consensus-critical design. Along with Maxwell and Wuille's recent findings=B9 CVE-2014-3570 - strong evidence of the excellent testing the library has undergone - I personally am now of the opinion that migrating Bitcoin Core to libsecp256k1 in the near future is a good idea on the grounds that it provides us with a well-written, and well-understood library designed with consensus in mind that'll probably give us fewer consensus problems than our existing OpenSSL dependency. It'll also help advanced protocol implementations by giving them a clear dependency to use when they need consensus-critical signature evaluation. 1) https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_not= es_say_we_have_reason_to/ --=20 'peter'[:-1]@petertodd.org 000000000000003b82d8644b56c846e7497118b04a6ec68d3e0a23d33323b82e --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUsLtSXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwNDk4ZGI3OTRjOGRkM2U2OGIxZDVmOTRkNTFkYjQ5NzM5ZTNk ZDc4OTFlNzMxNWIxZGIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft+eggAqMu14OQabJRJDwBBeD+2zN5h 15Z56MQN8WuzlgCoIL51jrnaAMVpmBfHZLxzksn5VUe30H+QiopnD27yUlC+sIqt yaHMdw0lrXAMeqA+LRkH5wxgozRY/TSqiDuO4x/gKe5vT36Mzjr0cSN57nvsBCGC D+r1O6IjVMEGmFD0mEV1f8b63WYP/hcGOOifNp9SgYXnhn2a2PW0xTmZvpxtZZr6 vYwHDq854jNh/kWrpoZFVllwRujMbxigydy79YzjynlBS8+CwuQq8caHJ3ScnIf2 uz114AWklGnwkrdJM6ENVNkrdFdOgjw1qiacsuZThGffeAwERgK2kE3QgmGMkA== =FG6G -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z--