Delivery-Date: Thu, 23 Oct 2014 19:30:20 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 756351E08C8;
	Thu, 23 Oct 2014 19:30:19 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 33B2C3102E;
	Thu, 23 Oct 2014 23:30:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id A30AC3104F
 for <tor-talk@lists.torproject.org>; Thu, 23 Oct 2014 23:30:11 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MnQ7LM2uASb2 for <tor-talk@lists.torproject.org>;
 Thu, 23 Oct 2014 23:30:11 +0000 (UTC)
Received: from turtles.fscked.org (turtles.fscked.org [76.73.17.194])
 by eugeni.torproject.org (Postfix) with ESMTP id 766662C9FB
 for <tor-talk@lists.torproject.org>; Thu, 23 Oct 2014 23:30:11 +0000 (UTC)
Date: Thu, 23 Oct 2014 16:29:21 -0700
From: Mike Perry <mikeperry@torproject.org>
To: tor-talk@lists.torproject.org
Message-ID: <20141023232921.GF21428@torproject.org>
References: <20141023191048.17a50660@meilong>
MIME-Version: 1.0
In-Reply-To: <20141023191048.17a50660@meilong>
Subject: Re: [tor-talk]
 =?utf-8?q?Bitcoin_over_Tor_isn=E2=80=99t_a_good_idea_?=
 =?utf-8?q?=28Alex_Biryukov_/_Ivan_Pustogarov__story=29?=
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2914214927292706404=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============2914214927292706404==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="Bqc0IY4JZZt50bUr"
Content-Disposition: inline


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

=C3=96yvind Saether:
> http://arxiv.org/pdf/1410.6079v1.pdf
>=20
> "Abstract
> =E2=80=94Bitcoin is a decentralized P2P digital currency in which coins a=
re
> generated by a distributed set of miners and transaction are
> broadcasted via a peer-to-peer network. While Bitcoin provides some
> level of anonymity (or rather pseudonymity) by encouraging the users to
> have any number of random-looking Bitcoin addresses, recent research
> shows that this level of anonymity is rather low. This encourages users
> to connect to the Bitcoin network through anonymizers like Tor and
> motivates development of default Tor functionality for popular mobile
> SPV clients. In this paper we show that combining Tor and Bitcoin
> creates an attack vector for the deterministic and stealthy
> man-in-the-middle attacks. A low-resource attacker can gain full
> control of information flows between all users who chose to use Bitcoin
> over Tor. In particular the attacker can link together user=E2=80=99s
> transactions regardless of pseudonyms used, control which Bitcoin
> blocks and transactions are relayed to the user and can delay or
> discard user=E2=80=99s transactions and blocks. In collusion with a power=
ful
> miner double-spending attacks become possible and a totally virtual
> Bitcoin reality can be created for such set of users."
>=20
> Interesting quote:
>=20
> "Combining it with some peculiarities of how Tor handles data streams a
> stealthy and low-resource attacker with just 1-3% of overall Tor Exit
> bandwidth capacity and 1000-1500 cheap lightweight Bitcoin peers (for
> example, a small Botnet) can force all Bitcoin Tor traffic to go either
> through her Exit nodes or through her peers. This opens numerous attack
> vectors."
>
> a) Does this paper hold water? b) What is the price of 1-3% of all Tor
> Exit capacity and "1000-1500 cheap lightweight" Bitcoin peers?

I skimmed this paper this morning, and the crux of the attack is the
interplay of the Bitcoin DoS protection mechanisms and the limited
supply of Tor Exit IPs.

Basically, you cause most Bitcoin peers to end up deciding to ban all
Tor Exit IPs except your exits, and then you are able to observe all
Tor+Bitcoin users, and maybe even feed them divergent versions of the
blockchain (assuming you can muster enough proof of work to hit the
difficulty), or easier still: hide certain unconfirmed transactions. The
amount of capacity you have basically governs how quickly you can expect
clients to converge on your exit (after failing with all the other
exits).

The paper also points out that some Bitcoin clients were hoping to use
Tor to obtain multiple network perspectives on unconfirmed transactions,
to provide additional confidence that you can accept an unconfirmed
transaction before it hits the blockchain. Obviously, if you are able to
control exits used for this, you can fool such clients into accepting
double-spends.=20

Personally, I think Bitcoin clients are still much better off
double-checking transactions via Tor than trusting only the local wifi
network, especially for accepting quick, unconfirmed transactions. But
it is useful to know that a naive "dude, just shove it through Tor,
man!" solution to this problem is not the best one.

The countermeasures section at the end is pretty good, though. In
addition to either tweaking or disabling the IP-based rate limiting for
Tor nodes, they also recommend encrypting bitcoin peer protocol traffic
(hard, but should probably be done for lots of reasons), or making use
of Bitcoin peers who also have Tor hidden service addresses available
(easy, and the paper provides a list of these that were found to exist
already in the wild).

One can also imagine that such bitcoin clients could also use a Tor
control port library to enforce that they actually are able to use a
certain number of independent exit families without failure, too. This
was not suggested, but it is possible.


It struck me as a notable work with respect to Tor because it is yet
another (surprising) area where having some kind of anonymous credential
system for proof of sacrifice/scarcity could benefit not only Tor users,
but also the rest of the Internet as well. It is also interesting
because right now, the naive proposal people often make for such systems
is "dude, just use Bitcoin, man!", but clearly we now have a catch-22
here (in addition to the privacy issues with Bitcoin).



--=20
Mike Perry

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

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUSY9RAAoJEEEC+JXS8eGGpaAP/3Gywt+1GPpF1rH8AcucP6IY
zNyL4tVn0ueH93ZVDKufyJzfawM+Lq06z8l5UBN7iWlZkPQ0of6dFOn9dmjwcwOP
mRWpiholutPOcfJKBngiaavdi/75Jmu00kY+AyGGZ95Mrm+FpGjI3APYBzQKO2m+
WBHK0HxueuX3t+dd0rwt8i6p5I/6oTx9+nqBu+wDOVjgr4AePiGt4Y6qJr/y03x8
RBd4MPh6kL5cvh6Uungm3V3Qw3aSgTRJGITW/Pae+qHqSlxySb1lh07lo6Vs8fxD
/8tx9j4K3lzurJsRirrETuQN60koXHeZcZnqiwM3MzUft48ycefV8tpb37edIFpN
ruFILsYa1rW5Q0KUxYxv50RQ4lEsf3iO4C7pSB2T1BKvCyQDBiSbM1eFcars3muw
0Wyi0YrmaeKMOS4d5rlWX5h2UlarWv0om510l9FCNc5EIhVZTeyaUA9y+J7DtqPG
jhtJQtKDJM8ygVp1qo+puqZ/+fLh8B06BhV+MqPpysrBAQKWA+xATkgQLTFQ4Ekg
AQ8JS00PZ/3SFFjOnmhim8f/aP17uk60EJoR3OgBpsYyBzu2n38fFge5qzipPmuX
KRCVFgIWYwtQkuuLBlsUSvXCPHzl3EwlxUVKs5dM99/RZdoxC288WV3/ElAyaDm3
n4BxVSfVZ+NEWO2VETVl
=aefq
-----END PGP SIGNATURE-----

--Bqc0IY4JZZt50bUr--

--===============2914214927292706404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

--===============2914214927292706404==--

