From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLHfD-0007Q3-Ld for bitcoin-development@lists.sourceforge.net; Wed, 05 Mar 2014 19:39:35 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WLHfB-00074a-M6 for bitcoin-development@lists.sourceforge.net; Wed, 05 Mar 2014 19:39:35 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s25JdQs9063142; Wed, 5 Mar 2014 19:39:26 GMT Received: from tilt ([64.210.40.106]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s25JdCB6047036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 19:39:22 GMT Date: Wed, 5 Mar 2014 14:39:10 -0500 From: Peter Todd To: Kevin Message-ID: <20140305193910.GA24917@tilt> References: <53174F20.10207@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <53174F20.10207@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: db130dc6-a49d-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgcUFVQGAgsB AmIbWl1eU1R7W2c7 bQ5PbwRdfE5OQQRq VldMSlVNFUsrAxl7 Um1sVBl2cAVFfjBx ZEJiVz4PDkV5dRIu RFMFEWRSeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4tEyF0 XBEOEH0kHUQDQSg3 ZxU6NlcXHw4NMkwu eVAoXxoCPhQVFABE fQlnATNSIFgHDykm HBgy X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 64.210.40.106/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -0.9 (/) 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.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [64.210.40.106 listed in dnsbl.sorbs.net] -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1WLHfB-00074a-M6 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys 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: Wed, 05 Mar 2014 19:39:35 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote: > On 3/5/2014 7:49 AM, Mike Hearn wrote: > >A new practical technique has been published that can recover > >secp256k1 private keys after observing OpenSSL calculate as little > >as 200 signatures: > > How can we patch this issue? If you're following good practices you're not particularly vulneable to it, if at all, even if you make use of shared hosting. First of all you shouldn't be re-using addresses, which means you won't be passing that ~200 sig threshold. More important though is you shouldn't be using single factor Bitcoin addresses. Use n-of-m multisig instead and architect your system such that that every transaction that happens in your service has to be authorized by both the "online" server(s) that host your website as well as a second "hardened" server with an extremely limited interface between it and the online server. The hardened second factor *should* use a separate codebase, ideally even a second language, to authenticate actions that withdraw funds or generate new addresses based on data given to it by the online server. In the best case your customers are PGP-signing requests so you can verify their intent independently and cryptographically on both servers. Mircea Popescu's MPEx exchange is an example of this model, although I don't think they're doing any multisig stuff. Failing that you can at least use the second server to do things like limit losses by flagging higher-than-expected withdrawl volumes and unusual events. Since this second-factor server only deals with business logic - not the website - you can certainly find a secure hosting arrangement for it with physical control. I recommend you stick the machine in your apartment and use tor + hidden services to connect to it from your VM instances. Note too that even if all you're doing is accepting Bitcoins from customers, perhaps in exchange for goods, all of the above *still* applies modulo the fact that the payment protocol is very incomplete. With P2SH (finally!) supported in all the major Bitcoin wallets there simply is no excuse not to have such an architecture other than lazyness and transaction fees; if you fall into the latter category you're business may very well be wiped out anyway by increased fees. --=20 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTF31YAAoJECSBQD2l8JH7YRgH/RWfc6FiyQUBidb5bu2or1vQ nSheu7XNakv6gjS6yAhn1tozJyfYS6ExN4seqUwLHVGpLIFm7nm82PMERs6lzttT bb6OALp4sJgjnIJjiQOWhFY5m8aGDxhicSkI39H2MwuAtRmiF5FDCqu6HDZGCUpx ZM7l0TkEiEk2FG5/ly1myvg1LC++bdd26/K/3UsU9kmLBj5+NUi93EA8Tpag7nvW I9OddGco3D+OtJVdRHnFRhSaWtFh9i15IdfVoH7aoMLtrvH333acDNBYBD2Ed4fl tC9mpEG/qTat21Y4xgRv1kdWzEmaLTgaZGjx3TTyK5JFFi9j+m5C04iyBx60owg= =F/ap -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/--