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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam.back@gmail.com>) id 1UZPm4-0004v7-7Y
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:04:32 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.83.48 as permitted sender)
client-ip=74.125.83.48; envelope-from=adam.back@gmail.com;
helo=mail-ee0-f48.google.com;
Received: from mail-ee0-f48.google.com ([74.125.83.48])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UZPm3-0001hy-3Q
for bitcoin-development@lists.sourceforge.net;
Mon, 06 May 2013 18:04:32 +0000
Received: by mail-ee0-f48.google.com with SMTP id d4so1945189eek.21
for <bitcoin-development@lists.sourceforge.net>;
Mon, 06 May 2013 11:04:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=x-received:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to
:user-agent:x-hashcash:x-hashcash:x-hashcash:x-hashcash;
bh=Zag7u4k0bqyzNxdB30OPTNQo7uSIiYeXM3LzPl5c5h0=;
b=BV071iLrwcGTUHnRLHNjbeNmMkm25+tpaOSsCu3CX98gpTT05LmFl8ZSjES+GS/alR
G91GXFjjAkVZryCNgrb5fnAXHsCLvfiKnRuPDkX+dQvq1iH94IE8JQHs6Z/hYqFdov8U
rbDi3Gb/lMw2KM+bmxog5+kXxPGoKXhNzkMQBMRc0TeVO280YLmEvb0aneHev8T6rcIV
wiadbACIRXdBB1UlEOAZcDePK10YE9GWmeOE+hWE8EbZ7CTbBtgTFITrF8882FrTwBWo
lfNgqtUVSN6/BvlUusHnZPNmmvDbLx8sfwBXoSE/ImB4uvepWcrN4WIFLogEV88ZXdjt
3kLA==
X-Received: by 10.14.205.194 with SMTP id j42mr39789839eeo.41.1367863464692;
Mon, 06 May 2013 11:04:24 -0700 (PDT)
Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90])
by mx.google.com with ESMTPSA id c44sm31453420eeb.4.2013.05.06.11.04.22
for <multiple recipients>
(version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 06 May 2013 11:04:23 -0700 (PDT)
Received: by netbook (Postfix, from userid 1000)
id 1D1462E064D; Mon, 6 May 2013 20:04:21 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Mon, 6 May 2013 20:04:19 +0200
Date: Mon, 6 May 2013 20:04:18 +0200
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130506180418.GA3797@netbook.cypherspace.org>
References: <CANEZrP1YFCLmasOrdxdKDP1=x8nKuy06kGRqZwpnmnhe3-AroA@mail.gmail.com>
<20130506161216.GA5193@petertodd.org>
<CA+8xBpfdY7GsQiyrHuOG-MqXon0RGShpg2Yv-KeAXQ-503kAsA@mail.gmail.com>
<20130506163732.GB5193@petertodd.org>
<CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <CANEZrP2WqXZVRJp6ag=RC4mSkt+a6qTYYpvE=DW_0Rdr=_BBHA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:130506:mike@plan99.net::Z70aeXc6yBzVMIND:004z9D
X-Hashcash: 1:20:130506:pete@petertodd.org::kpHU94brGdXhmcdX:0000000000000000000
0000000000000000000000004BVn
X-Hashcash: 1:20:130506:bitcoin-development@lists.sourceforge.net::35JOxe8irxEs1
JOX:000000000000000000000cZN
X-Hashcash: 1:20:130506:adam@cypherspace.org::VVtvsTjcc294UK4n:00000000000000000
0000000000000000000000001Z+t
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(adam.back[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1UZPm3-0001hy-3Q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)
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: Mon, 06 May 2013 18:04:32 -0000
Bitcoin p2p seeding requirements hav some ToR similarities, and we went
through the same security considerations with Zero-Knowledge systems freedom
network. Though bitcoins attacker profile and motivation is different - so
the defense maybe even more demanding. At least you have no shortage of
nodes and perhaps merchant interest and general good-will to lean on.
At ZKS I proposed we should fix the exit node issue (exit sees where you go
often in the clear) with an apache mod so the freedom aip tunnel (ToR tunnel
equiv) could terminate right on the web site. (ZKS freedom network is long
dead but some of the ideas I think made it into ToR, eg I hope my end2end
forward anonymity idea that is implemented in Zach Brown's cebolla.)
Anyway I'd have about DNS being of limited value: bitcoins primary
vulnerability IMO (so far) is network attacks to induce network splits,
local lower difficulty to a point that a local and artificially isolated
area of the network can be fooled into accepting an orphan branch as the
one-true block chain, maybe even from node first install time.
(btw I notice most of the binaries and tar balls are not signed, nor served
from SSL - at least for linux).
Therefore as it applies to discover, you want to be able to discover peers
through as many network routes, and even steganographic protocols as
possible. eg if a popular web server (say apache, or an apache module) put
a steganographic peer discover relay from its own network area, even for a
small bitcoin fee, that would help a lot. (Steganographic in the SSL sense
would just mean that the peer seed request to /btcseed.cgi would not be
distinguishable to someone highly sophisticated on the inside of the router
all the peers traffic is routed through. Eg you could easily do this with a
special magic header that overwrites something else or deletes some
unnecessary header so that the request at least is a standard size, and pad
the response to the same size as the site index.html or whatever). If the
user picks a few SSL sites and cross checks (more for high value) a subset
of peers available on all and uses them as his seed that seems like a better
direction.
In that way an attacker cant control the network without denying service to
popular SSL sites, which would be a warning sign to users, or having at his
disposal a SSL sub-CA cert (like happened with diginotar and gmail). You
may be able to pin CAs for popular sites. Obviously to the extent you're
using SSL you want to generally use EDH for forward-secrecy. And not RC4 :)
Probably anysite that accepts bitcoin payment will be happy to run such a
mod-bitcoin.
With ToR, it has a similar bootstrap problem to bitcoin. So while that may
help it is also passing the buck, not necessarily solving the problem. And
as I said I think its possible bitcoin has a higher assurance need in that
the attackers motivated my $$ might put more effort in than the odd
dictatorship trying to pay lip service to preventing people reading pages on
a blacklist.
Given the vulnerability of DNS to poisoning I would not trust it too much.
I know its just a bootstrap, but ideally you dont want to bootstrap from a
known publicly vulnerable protocol - it invites DNS poison net splits
against new users.
Also to the extent that users local clock is under his control (with
unuthentcated NTP?) he should also treat sudden dramatic changes in luck
(deviations from 10min interval) as suspicious.
Unfortunately at present because of the first past the post nature of the
bitcoin lottery, reduced variance hashcash cannot be used, so its hard to
infer too much even from quite significant luck changes.
Adam
On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
>> Speaking of, off-topic for this discussion, but in the future
>> node-to-node communicate should be encrypted and signed
>
>Yes, I'd like to do this. The threat isn't really ISPs which are
>mostly trustable (the worst they normally do outside of places like
>China is dick about with ads), the big threat is people who use
>untrusted WiFi without realising and end up thinking they received
>money when actually they were just connected to a hotspot running in
>the attackers pocket. I'm rather expecting that kind of thing to
>happen in future.
>
>I think we can converge on the best solution with several iterations:
>
>Iteration 1) Make it clear in the UI that if the phone is connected to
>WiFi, payments from untrusted people should not be accepted. Currently
>the Android app merely says the money won't be spendable for a few
>minutes. It needs to communicate the "may not exist" aspect more
>clearly. If you're connected via a cell tower, the existing wording is
>fine - it's very unlikely your telco is trying to scam you in a
>person-to-person transaction, traffic is encrypted and 3G+ connections
>authenticate the network so you can't be MITMd except by your telco.
>Assuming you have a good list of IPs, of course.
>
>Iteration 2) Give nodes keys that appear in addr broadcasts and seed
>data (whether it be via https or otherwise), and have each node keep a
>running hash of all messages sent on a connection so far. Add a new
>protocol message that asks the node to sign the current accumulated
>hash. Not all messages really need to be signed, eg asking for
>signatures of blocks is sort of pointless at high difficulty levels
>because the structures are self proving and a simple watchdog timer
>that looks for unusually slow progress is probably enough. If the
>client keeps the same accumulated hash then when you encounter
>something you care about the accuracy of, you can ask for a signature
>over all traffic so far.
>
>Iteration 3) Do something about end to end encryption, just delegate
>everything to Tor, or find some other way to obfuscate the origin of a
>transaction (a mini onion network for example).
>
>Last time I looked, Tor wasn't really usable in library form and
>connecting to hidden services is really slow. So it'd be an issue to
>just re-use it out of the box, I think.
|
