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

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

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.

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.
-- 
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