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

[s7r <s7r@xxxxxxxxxx>]

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