Delivery-Date: Fri, 31 Oct 2014 00:54:28 -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=-3.0 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,
	URIBL_BLACK 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 CBCBE1E0CC0;
	Fri, 31 Oct 2014 00:54:26 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 80DF131826;
	Fri, 31 Oct 2014 04:54:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 712233181A
 for <tor-talk@lists.torproject.org>; Fri, 31 Oct 2014 04:54:17 +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 3pd-pzOmvUDO for <tor-talk@lists.torproject.org>;
 Fri, 31 Oct 2014 04:54:17 +0000 (UTC)
Received: from mail-la0-x244.google.com (mail-la0-x244.google.com
 [IPv6:2a00:1450:4010:c03::244])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 952DF31814
 for <tor-talk@lists.torproject.org>; Fri, 31 Oct 2014 04:54:13 +0000 (UTC)
Received: by mail-la0-f68.google.com with SMTP id mc6so781031lab.3
 for <tor-talk@lists.torproject.org>; Thu, 30 Oct 2014 21:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=2GgcThjVmnFspJ++G0p+nN6+53JxdKJHfYzMu+JjfV4=;
 b=nJMzxBdkabvlON+Z4emdNaAecsZg6k92qj5DMNt4HJGQ6oS8soL0Y14G9yVv018byg
 gGagjjj9Pj2X4Z9XGE5xxVcBDaZzTU0o3jiyphck6eYR36ZIBcHqa+kOBnbD85RzVUr4
 Nhf6jR+bx5udi52SmZqKcpY7JoMEJD/vArzdHbxe1UOS1+k5/+JqnpM3LoSn5UehNWui
 fykft0/27hZ5zlwsN0slXM2IVRTcAdXDAF7w8OqX718EfwPUbfZDe23PWjZTjxzO/sAk
 6lk/Px7mGTfnU+z2/A4tSyQeeVGNJ5M2rXGz1RAFoHFvWmkY1pISNjZIy34MxDHsQIac
 OmNw==
MIME-Version: 1.0
X-Received: by 10.152.2.100 with SMTP id 4mr23370914lat.6.1414731250149; Thu,
 30 Oct 2014 21:54:10 -0700 (PDT)
Received: by 10.152.242.2 with HTTP; Thu, 30 Oct 2014 21:54:10 -0700 (PDT)
In-Reply-To: <545280FC.2020204@sky-ip.org>
References: <20141023191048.17a50660@meilong>
 <20141023232921.GF21428@torproject.org>
 <20141024103527.fd3ac8eff8862bf101b45d95@mega-nerd.com>
 <CAD2Ti2_QWc1Xq+uTvmurFLqjLVsSACMYYDzTAs7zk5SWyQE7Cw@mail.gmail.com>
 <544EA504.6070201@riseup.net> <544EC788.1010701@sky-ip.org>
 <544ed302.0905430a.09c3.ffffec4aSMTPIN_ADDED_BROKEN@mx.google.com>
 <CAAS2fgQWfyV0UAABi1Cj4_qienaqhd-WM-PwKG0yQ+e8RthDEw@mail.gmail.com>
 <545280FC.2020204@sky-ip.org>
Date: Fri, 31 Oct 2014 00:54:10 -0400
Message-ID: <CAGH37SLfBFDBjd_wB-yrgwiv-ZdEjfY0WBJtVvmq5ChnG=U1eQ@mail.gmail.com>
From: Kristov Atlas <kristovatlas.lists@gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

I started working on a web app to provide stats that may reveal such an
attack in progress. It's in the early stages, so feedback on how to improve
it is welcome.

http://openbitcoinprivacyproject.org/torban/www/

-Kristov Atlas

On Thu, Oct 30, 2014 at 2:18 PM, s7r <s7r@sky-ip.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> On 10/30/2014 6:51 AM, Gregory Maxwell wrote:
> > On Mon, Oct 27, 2014 at 11:19 PM, Seth David Schoen
> > <schoen@eff.org> wrote:
> >> First, the security of hidden services among other things relies
> >> on the difficulty of an 80-bit partial hash collision; even
> >> without any new mathematical insight, that isn't regarded by NIST
> >> as an adequate hash
> >
> > So?  80 bits is superior to the zero bits of running over the open
> > internet?
> >
> > (You should be imagining me wagging my finger at you for falling
> > into the trap of seeming to advance not using cryptographic
> > security at all since it's potentially not perfect)
> >
> >> service user and the hidden service operator is not as
> >> trustworthy in some ways as a modern TLS implementation would
> >> be.
> >
> > Hah. Well here modern TLS seems to be mostly a cluster@#$@ of
> > complexity and resulting protocol an implementation failure. :)
> >
> > But thats not here nor there, because it isn't actually a choice
> > offered.
> >
> >> Second, a passive attacker might be able to distinguish Bitcoin
> >> from other protocols running over Tor by pure traffic analysis
> >> methods.  If a new user were downloading the entire blockchain
> >> from scratch, there would be a very characteristic and
> >> predictable amount of data that that user downloads over Tor
> >> (namely, the current size of the entire blockchain -- 23394
> >> megabytes as of today).
> >
> > Sure, though thats a one time transfer common to all Bitcoin
> > users. Which the user may have already had most of previously, or
> > obtained from some other source.
> >
> > At worst, that traffic has just identified you as someone who has
> > started up a Bitcoin node.
> >
> >
> >> Not many files are exactly that size, so it's a fairly strong
> >> guess that that's what the user was downloading.  Even submitting
> >> new transactions over hidden services might not be very similar
> >> to, say, web browsing, which is a more typical use of Tor.  The
> >> amount of data sent when submitting transactions is comparatively
> >> tiny, while blockchain updates are comparatively large but aren't
> >> necessarily synchronized to occur immediately after transaction
> >> submissions.  So maybe there's a distinctive statistical
> >> signature observable from the way that the Bitcoin client submits
> >> transactions over Tor.  It would at least be worth studying
> >> whether this is so (especially because, if it is, someone who
> >> observes a particular Tor user apparently submitting a
> >> transaction could try to correlate that transaction with new
> >> transactions that the hidden services first appeared to become
> >> aware of right around the same time).
> >
> > Bitcoin core intentionally obscures the timing of its transaction
> > relaying and batches with other transactions flowing through. It
> > could do much better, the existing behavior was designed before we
> > had good tor integration and so didn't work as hard at traffic
> > analysis resistance as it could have.
> >
> > In some senses Bitcoin transaction propagation would be a near
> > ideal application for a high latency privacy overlay on tor, since
> > they're small, relatively uniform in size, high value, frequent...
> > and already pretty private and so are unlikely to gather nuisance
> > complaints like email remailers do.
> >
> >> Third, to take a simpler version of the attacks proposed in the
> >> new paper, someone who _only_ uses Bitcoin peers that are all run
> >> by TheCthulhu is vulnerable to double-spending attacks, and even
> >> more devious attacks, by TheCthulhu.  (You might say that
> >> TheCthulhu is
> >
> > Bitcoin has a fair degree of robustness against network sybils,
> > and even if all your peers are a single malicious party their
> > ability to attack is gated by the several thousand dollar per block
> > costs (and the risk that the receiver will realize something is
> > wrong when it takes days to get six confirmations).
> >
> > (New client software comes with foreknowledge of the work in the
> > real network, so you cannot even provide a replacement alternative
> > history without doing enormous amounts of computation, e.g. 2^82
> > sha256 operations currently to replicate the history).
> >
> > More mechanisms to reduce sybil risk are important for onion peers
> > and IPv6 where address scarcity are unavailable and people have
> > been experimenting with various ideas to address those and related
> > concerns, e.g. https://bitcointalk.org/index.php?topic=310323.0
> > and https://en.bitcoin.it/wiki/Identity_protocol_v1, but the
> > system already assumes that the peers are attackers generally.
> >
> >> but that does at least undermine the decentralization typically
> >> claimed for Bitcoin because you have to trust a particular hidden
> >> service operator
> >
> > As above, at least the 'trusted' operator has considerable costs
> > to attack you... This is arguably a much stronger security model
> > than using tor in the first place due to tor's complete reliance
> > on directory authorities, for all you know you're being given a
> > cooked copy of the directory and are only selecting among
> > compromised tor nodes. This is one of the reasons that a some
> > amount of work has gone into supporting multi-stack network
> > configurations in bitcoin, so that you can have peers on each of
> > several separate transports.
> >
> >> Using Bitcoin over Tor hidden services might be a good choice for
> >> most users today who want their transactions and private key
> >> ownership to be as private as possible, but it's not free of
> >> risk, and it's probably not an appropriate long-term solution to
> >> recommend to the general public without fixes to some of the
> >> technologies involved!
> >
> > Normally when used with tor bitcoin nodes will use both HS and
> > non-HS peers, and if non HS peers are available it will not use
> > more than 4 non-HS peers.
> >
> How will bitcoind know when it is used with Tor in order to use max. 4
> non-HS peers? You mean when onion= is set? Or if the socks5 address is
> 127.0.0.1:9050 bitcoind assumes it is Tor and adopts the corresponding
> behavior?
>
> By default, a non-HS (normal) node will have in peers.dat file both
> clearnet nodes and HS nodes?
>
> > However, because of the way tor's exit selection works the non-HS
> > peers usually end up entirely connecting through a single exit,
> > which is pretty pessimal indeed. We'd certainly like more control
> > of that, but the ability to create hidden services over the control
> > port would be a higher priority IMO... since right now it's almost
> > pointless to improve robustness to HS sybils when so few people go
> > through the considerable extra configuration to enable running a
> > hidden service.
> >
> > On Wed, Oct 29, 2014 at 3:41 PM, eric gisse <jowr.pi@gmail.com>
> > wrote:
> >> ...and this is precisely why I asked! The documentation on
> >> setting up a bitcoin node is very....sparse, so I had to guess.
> >
> > There is a whole separate document on this, I'm not sure what else
> > you're looking for:
> > https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md
> >
> > I'm not sure where you found "tor=" as that hasn't been a
> > configuration option for over a year. Originally it was the
> > setting for specifying a proxy to be used exclusively to reach HS
> > peers-- a somewhat advanced usage (e.g. when you want to be able to
> > connect to HS but the regular clearnet IPv4/IPv6 internet for your
> > other connections), and clearly documented as such... but users in
> > a rush were sometimes setting it. That option is now called
> > -onion.
> >
> >
> > Good to hear about the reduced exit policy, in general there have
> > been virtually no(*) reports of bitcoin node operators being
> > harassed.
> >
> >
> > (*) one exception: https://github.com/bitcoin/bitcoin/issues/2653
> > but here if it was even real it was from someone listening, it
> > seems, not making outbound connections.
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUUoD8AAoJEIN/pSyBJlsR2zwH/1mwNUEUdPaRiJzlpTm6YABV
> Aye0/wVFtR3s8wQhY1LU9HBHYY+8IAkyieZDJy3kt2cde73bN8zagchdNmD/R8Qr
> L+nshw9qZCRqgojj//IvuOjWqsvjXKXBJBik3xYNrXWv/sQ04akgokBUJIJb1tkA
> gReJdEoloYl3CL0ZdSsbv15osEVw7v1ahlMKNGpKVFtHbVrVDJV1dneXb8uuQIic
> c2d6GYFKJw0/qn8NLMuB87Au7kRUr3vDNt0WMScb43VDZRc7sMz9jwphelGSQjF2
> pCrnG2D49rMpHEzvWoKmSWNHDcf6SaYHV1L1htDgw/uRwnuATGnyzJf1sD4HS44=
> =VhSK
> -----END PGP SIGNATURE-----
> --
> 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
>
-- 
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

