From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XJUBZ-0000Ep-9i for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 21:09:49 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of uni.lu designates 158.64.76.33 as permitted sender) client-ip=158.64.76.33; envelope-from=ivan.pustogarov@uni.lu; helo=hercules.uni.lu; Received: from hercules.uni.lu ([158.64.76.33]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XJUBX-0006Dp-AI for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 21:09:49 +0000 X-IronPort-AV: E=Sophos;i="5.01,888,1400018400"; d="scan'208";a="48413953" Date: Mon, 18 Aug 2014 23:02:57 +0200 From: Ivan Pustogarov To: Gregory Maxwell Message-ID: <20140818210257.GB639@localhost.localdomain> References: <20140818164543.GB31175@localhost.localdomain> <20140818183721.GD31175@localhost.localdomain> <20140818203343.GA639@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.24.1.80] X-Spam-Score: -2.2 (--) 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_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1XJUBX-0006Dp-AI Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Outbound connections rotation 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, 18 Aug 2014 21:09:49 -0000 For each neighbour, a Bitcoin peer keeps the history of addresses that it forwarded to the neighbour. If an address was already forwarded to a neighbour it is not retransmitted again. An attacker can make a list of potential IP addresses of clients (say an IP range of an ISP, or listen for addresses in the Bitcoin network before the attack). Then she periodically "spams" the network with this list and updates the address-forward history at each Bitcoin peer. After each "spam" round, the attacker reconnects her connections to Bitcoin peers and thus clears the retransmission history for her connections only. As the result, when a NAT client connects to the network and advertises its address, the addresses will propagate to the attacker's connections only. On Mon, Aug 18, 2014 at 01:43:44PM -0700, Gregory Maxwell wrote: > On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov wrote: > > The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin > > It was discussed here: https://bitcointalk.org/index.php?topic=632124.0 > > > > It uses the following observation. Each NATed client connects to the Bitcoin network > > through 8 entry peers; he also advertises his public IP address to these peers which > > allows an attacker to make the mapping <8-entry-peers, client-IP-address>. > > I'm afraid I'm losing you here. The node advertises himself to > everyone he is connected to and in/or out, those nodes pass along > those advertisements. When I receive an advertisement from a node I > do not know how far away the advertised peers is, presumably I can > accurately exclude it from being 0-hops— itself—) 1 or more should be > indistinguishable. Is there a reason that they're distinguishable that > I'm missing? > > Can you explain to me how you propose to produce this mapping? -- Ivan