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