From: Peter Todd <pete@petertodd•org>
To: Kevin <kevinsisco61784@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Date: Wed, 5 Mar 2014 14:39:10 -0500 [thread overview]
Message-ID: <20140305193910.GA24917@tilt> (raw)
In-Reply-To: <53174F20.10207@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]
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.
--
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2014-03-05 19:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 12:49 Mike Hearn
2014-03-05 12:56 ` Pieter Wuille
2014-03-05 13:18 ` Jean-Paul Kogelman
2014-03-05 14:04 ` Pieter Wuille
2014-03-05 16:21 ` Kevin
2014-03-05 19:39 ` Peter Todd [this message]
2014-03-05 19:51 ` Gregory Maxwell
2014-03-05 20:32 ` Peter Todd
2014-03-05 20:54 ` Gregory Maxwell
2014-03-12 9:44 ` Peter Todd
2014-03-05 22:17 ` James Hartig
2014-03-05 22:26 ` Eric Lombrozo
2014-03-06 7:02 ` Odinn Cyberguerrilla
2014-03-08 19:34 ` Luke-Jr
2014-03-09 1:57 ` Gregory Maxwell
2014-03-05 21:31 ` Eric Lombrozo
2014-03-05 21:44 ` Gregory Maxwell
2014-03-05 22:14 ` Eric Lombrozo
2014-03-05 22:25 ` Gregory Maxwell
2014-03-06 8:38 ` Mike Hearn
2014-03-06 10:00 ` Natanael
2014-03-25 13:39 ` Troy Benjegerdes
2014-03-25 13:50 ` Gavin Andresen
2014-03-08 19:29 ` Gustav Simonsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140305193910.GA24917@tilt \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=kevinsisco61784@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox