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 <[email protected]> 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 > > <[email protected]> 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 <[email protected]> > > 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 - [email protected] > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
