📅 Original date posted:2014-03-06
📝 Original message: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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Odinn Cyberguerrilla [ARCHIVE] /
npub18x…hg6zk
2023-06-07 15:14:44
in reply to nevent1q…n4yz
Author Public Key
npub18xqykhf26udeq2nyk98ee0a5q4w3s2f75m405a6zswpdy573lxeqmhg6zkPublished at
2023-06-07 15:14:44Event JSON
{
"id": "e96930520a643623acb1c6955dae34fba5ba5e203066f52f90cb43abc1011d2c",
"pubkey": "39804b5d2ad71b902a64b14f9cbfb4055d18293ea6eafa77428382d253d1f9b2",
"created_at": 1686150884,
"kind": 1,
"tags": [
[
"e",
"d46bd1a40c3d916ca1e2c015ea0a2210ec8d4fdd9116c09aec6725abac0dd67f",
"",
"root"
],
[
"e",
"f5105a8f075b3371d4c13f2210e83d4e16a5b3bb0badee682ef970374621c0e2",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2014-03-06\n📝 Original message:One wonders also re. bitmessage, though that may not be relevant to this\nparticular list.\n\n\u003e On Wed, Mar 05, 2014 at 11:21:52AM -0500, Kevin wrote:\n\u003e\u003e On 3/5/2014 7:49 AM, Mike Hearn wrote:\n\u003e\u003e \u003eA new practical technique has been published that can recover\n\u003e\u003e \u003esecp256k1 private keys after observing OpenSSL calculate as little\n\u003e\u003e \u003eas 200 signatures:\n\u003e\u003e\n\u003e\u003e How can we patch this issue?\n\u003e\n\u003e If you're following good practices you're not particularly vulneable to\n\u003e it, if at all, even if you make use of shared hosting. First of all you\n\u003e shouldn't be re-using addresses, which means you won't be passing that\n\u003e ~200 sig threshold.\n\u003e\n\u003e More important though is you shouldn't be using single factor Bitcoin\n\u003e addresses. Use n-of-m multisig instead and architect your system such\n\u003e that that every transaction that happens in your service has to be\n\u003e authorized by both the \"online\" server(s) that host your website as well\n\u003e as a second \"hardened\" server with an extremely limited interface\n\u003e between it and the online server. The hardened second factor *should*\n\u003e use a separate codebase, ideally even a second language, to authenticate\n\u003e actions that withdraw funds or generate new addresses based on data\n\u003e given to it by the online server. In the best case your customers are\n\u003e PGP-signing requests so you can verify their intent independently and\n\u003e cryptographically on both servers. Mircea Popescu's MPEx exchange is an\n\u003e example of this model, although I don't think they're doing any multisig\n\u003e stuff. Failing that you can at least use the second server to do things\n\u003e like limit losses by flagging higher-than-expected withdrawl volumes and\n\u003e unusual events.\n\u003e\n\u003e Since this second-factor server only deals with business logic - not the\n\u003e website - you can certainly find a secure hosting arrangement for it\n\u003e with physical control. I recommend you stick the machine in your\n\u003e apartment and use tor + hidden services to connect to it from your VM\n\u003e instances.\n\u003e\n\u003e Note too that even if all you're doing is accepting Bitcoins from\n\u003e customers, perhaps in exchange for goods, all of the above *still*\n\u003e applies modulo the fact that the payment protocol is very incomplete.\n\u003e\n\u003e\n\u003e With P2SH (finally!) supported in all the major Bitcoin wallets there\n\u003e simply is no excuse not to have such an architecture other than lazyness\n\u003e and transaction fees; if you fall into the latter category you're\n\u003e business may very well be wiped out anyway by increased fees.\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3\n\u003e ------------------------------------------------------------------------------\n\u003e Subversion Kills Productivity. Get off Subversion \u0026 Make the Move to\n\u003e Perforce.\n\u003e With Perforce, you get hassle-free workflows. Merge that actually works.\n\u003e Faster operations. Version large binaries. Built-in WAN optimization and\n\u003e the\n\u003e freedom to use Git, Perforce or both. Make the move to Perforce.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=122218951\u0026iu=/4140/ostg.clktrk_______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "8de74c8bdbdb4fccc7e9e7bdbceff109879bf9c7aaaf2b3de9f2af4eeb033f82fb97f5d80b6c79cfbc8842f92eb35a08eb3a6396da1a6e1746bed9ce9aa2b262"
}