summaryrefslogtreecommitdiff
path: root/32/9a034b32606b99127c290215ad58f7e97d42f5
blob: d030f67ff329f89165adece878dcc3041709fc98 (plain)
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
147
148
149
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1WNfiG-0000jt-H7
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Mar 2014 09:44:36 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.108 as permitted sender)
	client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
	helo=outmail148108.authsmtp.net; 
Received: from outmail148108.authsmtp.net ([62.13.148.108])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WNfiF-0006sB-8a for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Mar 2014 09:44:36 +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 s2C9iSo9046359;
	Wed, 12 Mar 2014 09:44:28 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s2C9iK8v054963
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Wed, 12 Mar 2014 09:44:22 GMT
Date: Wed, 12 Mar 2014 05:44:24 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140312094424.GD15281@savin>
References: <CANEZrP25N7W_MeZin_pyVQP5pC8bt5yqJzTXt_tN1P6kWb5i2w@mail.gmail.com>
	<53174F20.10207@gmail.com> <20140305193910.GA24917@tilt>
	<CAAS2fgR+q4fDs3JfX9az8b17Dk7VKjC3SxYja-2spwU-kM74fA@mail.gmail.com>
	<20140305203222.GD24917@tilt>
	<CAAS2fgRTuOaSbTqnCOp=783gLCeh7ZU0FWbxzMS6pe8WKPTcLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="W5WqUoFLvi1M7tJE"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRTuOaSbTqnCOp=783gLCeh7ZU0FWbxzMS6pe8WKPTcLQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: e498a007-a9ca-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdwAUFVQGAgsB AmIbW11eVFl7W2A7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrA28I X2UWFBl3cwxAezBx YEFqXj4OWE1yJEZ9
	RVMFHD5XeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4tEyF0 XBEOEH0kHUQDQSg3
	ZxU6NlcXHw4NMkwu eVAoXxoCPhQVFABE fQlnATNSIFgHDykm HBgy
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1WNfiF-0006sB-8a
Cc: Bitcoin Development <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, 12 Mar 2014 09:44:36 -0000


--W5WqUoFLvi1M7tJE
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 05, 2014 at 12:54:04PM -0800, Gregory Maxwell wrote:
> On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd <pete@petertodd.org> wrote:
> > That's nice, but I wrote my advice to show people how even if they don't
> > know any crypto beyond what the "black boxes" do - the absolute minimum
> > you need to know to write any Bitcoin software - you can still defend
> > yourself against that attack and many others.
>=20
> But it's still incomplete.
>=20
> Say you have an address=E2=80=94 used only once!=E2=80=94 with a txout wi=
th a lot of value.
>=20
> Someone starts paying you small amounts to that address over and over
> again. You haven't asked them to, they're just doing it.
>=20
> Do you ignore the funds?=E2=80=94 maybe tell some customer that was ignor=
antly
> paying you over and over again to a single address "sorry, those are
> my rules: I only acknowledge the first payment, those funds are
> lost!".
>=20
> No, of course not.  You spend the darn coins and if you're on a shared
> host perhaps you disclose a private key.
>=20
> The probability of an attack actually going on is low enough compared
> to the cost of spending the coins in that case that even someone with
> good knoweldge of the risks will choose to do so.
>=20
> So absolutely, not reusing addresses massively increases your safety
> and limits losses when there is theft. But it isn't enough alone. (Nor
> is smarter signing, considering complex software like this has bugs
> and its hard to be confident that something is side channel free=E2=80=94=
 esp
> when you allow attacker interference).

I think you're misunderstanding me: I'm assuming one of the n parties
signing transactions in my multi-factor authentication scheme is
uncompromised - much easier to do when it's a low-bandwidth box sitting
in a secure location.

Not re-using keys is nice too of course, and while not perfect - your
above scenario - certainely helps limit losses.

--=20
'peter'[:-1]@petertodd.org
0000000000000000afcad9265e8b44bf1171a08165c09b329fab2893bf13ec69

--W5WqUoFLvi1M7tJE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTICxyXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDBhZmNhZDkyNjVlOGI0NGJmMTE3MWEwODE2NWMwOWIzMjlm
YWIyODkzYmYxM2VjNjkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuYtgf+J3atP/DXXxUVTPtEWL4+FWei
r3BQJ6rH1Eer8ScxO2xJxyYpNtLRxswhJAPIo7NyG5TtYiNIaaAfuPZi8+qXgRwk
IwIVJFoFqiqAldaHsRHtOeB04VhSqlwk4bUyvNGGRHCPh5GjoOVLgU1ev4X4cAR8
e06UJAhN2e6a7/UhCjzNweX1CIojpDKC78bdvDO245Yk9Lhubc2MFAajDOf1t6o1
J4dtf7t2eSavqYUR1TLhSjmoDWHQgeGPP6LXA2nWnQ1jPxOA5Ffm3y8Q83SkZPDx
VTlsNmQ7YZpX1rUcmG686sH0oNZshiO/ZGG62wzpI6SXSV7y0MkvRMiNQ09FFw==
=pbyf
-----END PGP SIGNATURE-----

--W5WqUoFLvi1M7tJE--