Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-05 📝 Original message:On Wed, Mar 05, 2014 at ...
📅 Original date posted:2014-03-05
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140305/f42ea4b1/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140305/f42ea4b1/attachment.sig>;