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