From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLSKZ-0005ul-WC for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 07:03:00 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WLSKX-0008KI-Cq for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 07:02:59 +0000 Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 64B8B4AD9B; Wed, 5 Mar 2014 23:02:51 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla@fulvetta.riseup.net) with ESMTPSA id F0C5E34C Received: from localhost (127.0.0.1) (SquirrelMail authenticated user odinn.cyberguerrilla) by fulvetta.riseup.net with HTTP; Wed, 5 Mar 2014 23:02:51 -0800 Message-ID: <2f64c4dbc080d876a68e4b12b31ad612.squirrel@fulvetta.riseup.net> In-Reply-To: <20140305193910.GA24917@tilt> References: <53174F20.10207@gmail.com> <20140305193910.GA24917@tilt> Date: Wed, 5 Mar 2014 23:02:51 -0800 From: "Odinn Cyberguerrilla" To: "Peter Todd" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.97.8 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1WLSKX-0008KI-Cq 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: Thu, 06 Mar 2014 07:03:00 -0000 One wonders also re. bitmessage, though that may not be relevant to this particular list. > 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 wel= l > 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 authenticat= e > 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 multisi= g > stuff. Failing that you can at least use the second server to do things > like limit losses by flagging higher-than-expected withdrawl volumes an= d > unusual events. > > Since this second-factor server only deals with business logic - not th= e > 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 lazynes= s > and transaction fees; if you fall into the latter category you're > business may very well be wiped out anyway by increased fees. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 > -----------------------------------------------------------------------= ------- > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works= . > Faster operations. Version large binaries. Built-in WAN optimization a= nd > the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/os= tg.clktrk_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >