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 <odinn.cyberguerrilla@riseup.net>) 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: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
	<53174F20.10207@gmail.com> <20140305193910.GA24917@tilt>
Date: Wed, 5 Mar 2014 23:02:51 -0800
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Peter Todd" <pete@petertodd.org>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
>