1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1WLHfD-0007Q3-Ld
for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 19:39:35 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WLHfB-00074a-M6 for bitcoin-development@lists.sourceforge.net;
Wed, 05 Mar 2014 19:39:35 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s25JdQs9063142;
Wed, 5 Mar 2014 19:39:26 GMT
Received: from tilt ([64.210.40.106]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s25JdCB6047036
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 5 Mar 2014 19:39:22 GMT
Date: Wed, 5 Mar 2014 14:39:10 -0500
From: Peter Todd <pete@petertodd.org>
To: Kevin <kevinsisco61784@gmail.com>
Message-ID: <20140305193910.GA24917@tilt>
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
<53174F20.10207@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <53174F20.10207@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: db130dc6-a49d-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgcUFVQGAgsB AmIbWl1eU1R7W2c7 bQ5PbwRdfE5OQQRq
VldMSlVNFUsrAxl7 Um1sVBl2cAVFfjBx ZEJiVz4PDkV5dRIu
RFMFEWRSeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4tEyF0 XBEOEH0kHUQDQSg3
ZxU6NlcXHw4NMkwu eVAoXxoCPhQVFABE fQlnATNSIFgHDykm HBgy
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 64.210.40.106/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[64.210.40.106 listed in dnsbl.sorbs.net]
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1WLHfB-00074a-M6
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] New side channel attack that can recover
Bitcoin keys
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 19:39:35 -0000
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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.
--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJTF31YAAoJECSBQD2l8JH7YRgH/RWfc6FiyQUBidb5bu2or1vQ
nSheu7XNakv6gjS6yAhn1tozJyfYS6ExN4seqUwLHVGpLIFm7nm82PMERs6lzttT
bb6OALp4sJgjnIJjiQOWhFY5m8aGDxhicSkI39H2MwuAtRmiF5FDCqu6HDZGCUpx
ZM7l0TkEiEk2FG5/ly1myvg1LC++bdd26/K/3UsU9kmLBj5+NUi93EA8Tpag7nvW
I9OddGco3D+OtJVdRHnFRhSaWtFh9i15IdfVoH7aoMLtrvH333acDNBYBD2Ed4fl
tC9mpEG/qTat21Y4xgRv1kdWzEmaLTgaZGjx3TTyK5JFFi9j+m5C04iyBx60owg=
=F/ap
-----END PGP SIGNATURE-----
--TB36FDmn/VVEgNH/--
|
