On 6/12/12 12:32 PM, Roger Dingledine wrote: >> Any attacker who can extend circuits through a bridge can enumerate >> the set of guard nodes which it routes its clients' circuits through. >> A malicious middle relay can easily determine the set of entry guards >> used by a hidden service, and over time, can determine the set of >> entry guards used by a user with a long-term pseudonym. If a bridge >> uses the same set of entry guards for its clients' circuits as it does >> for its own, users who operate bridges can be deanonymized quite >> trivially. > > I think that's a good reason to have the guards that clients get through > the bridge be different than the guards that the bridge uses for its > own traffic. > > I'll also note that this proposal may not be quite as high-priority > as it originally was, if we go the "multi-homed bridges" route: see > the parenthetical note at the bottom of attack #2 on > https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges > > --Roger
And it would be very useful if we would allow an easy way to setup hundreds of "dumb briges", simple TCP forwarding proxy that goes in a random order across all public relays. Easier to setup, available in big quantities. I would be pleased to use my *dsl/cable home-router with fixed-IP address to do a port-mapping to a known and stable tor-relay. Being able to "setup a bridge" by simply: - opening a port-forward on my router - submitting it to a web-interface would be a very cool way to open-up opportunities of hundreds or thousands of different IP:PORT pair (basically a bridge) without having to run dedicated software on an always on-server (replaced by a simple home-router, that's "the always-on server"). -naif _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev