Gregory Maxwell writes: > 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)
I meant this only as a response to the previous poster's remark that Hidden services are end-to-end encrypted so the risk of MITM between nodes does not exist. I think the risk of MITM between nodes is extremely small. But 80-bit partial preimages are still a disturbingly small safety margin today. It's kind of comparing apples to kumquats, but the current Bitcoin network as a whole has a hashrate that (if it were instead testing SHA1 hashes of RSA-1024 keys) could find such a partial preimage in 25 days, on average. While replicating the hashing power of the entire Bitcoin network is a truly staggering cost (to say nothing of the associated power bill), that isn't where I'd like to see the order of magnitude comparisons. > 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. Well, here, I was responding to the previous poster's claim that "nobody listening your wire can have a slight clue that you use bitcoin". > 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. Cool, that sounds like a great area for an enterprising researcher to investigate. > 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. Do you have a sense of how it would affect payees' concerns about double-spending attacks if the latency of transaction propagation were increased? Is the idea that privacy-enhancing latency additions are only meant for cases where receivers are already waiting for multiple 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). That's a clever idea. > 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. Tor's directory decentralization needs a lot of work, but the most practical sybil attack in Tor is just the original -- making a lot of compromised nodes and hoping a user will repeatedly pick them. It still seems pretty clear that this can work against many randomly selected Tor users at comparatively low cost (I'd agree that that's cheaper than attacking randomly-selected Bitcoin-over-Tor users with Bitcoin-related attacks, for the reasons you mention). On the other hand, I don't think we have a clear path for a would-be Tor directory / consensus subverter to follow. > 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. I wonder if anybody is working on that on the Tor end (or whether it has any unexpected security consequences). I guess it would mean that someone who can compromise even a heavily sandboxed Tor Browser would become able to use it as a hidden service server (at least while it was still running) without the knowledge of the browser's user. -- Seth Schoen <sch...@eff.org> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- 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
