On Mon, Oct 27, 2014 at 11:19 PM, Seth David Schoen <sch...@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. 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...@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. -- 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
