Re: [tor-talk] Bitcoin over Tor isnât a good idea (Alex Biryukov / Ivan Pustogarov story)

[Kristov Atlas <kristovatlas.lists@xxxxxxxxx>]

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@xxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk