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; 
Date: Wed, 5 Mar 2014 14:39:10 -0500
From: Peter Todd <pete@petertodd.org>
To: Kevin <kevinsisco61784@gmail.com>
Message-ID: <20140305193910.GA24917@tilt>
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
	<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)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New side channel attack that can recover
 Bitcoin keys
Precedence: list


--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/--