From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 (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 To: Mike Hearn Message-ID: <20130506180418.GA3797@netbook.cypherspace.org> References: <20130506161216.GA5193@petertodd.org> <20130506163732.GB5193@petertodd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.