public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Peter Todd" <pete@petertodd.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Date: Wed, 5 Mar 2014 23:02:51 -0800	[thread overview]
Message-ID: <2f64c4dbc080d876a68e4b12b31ad612.squirrel@fulvetta.riseup.net> (raw)
In-Reply-To: <20140305193910.GA24917@tilt>

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 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
> ------------------------------------------------------------------------------
> 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 and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>





  parent reply	other threads:[~2014-03-06  7:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 12:49 [Bitcoin-development] New side channel attack that can recover Bitcoin keys 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
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 [this message]
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=2f64c4dbc080d876a68e4b12b31ad612.squirrel@fulvetta.riseup.net \
    --to=odinn.cyberguerrilla@riseup.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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