Hi,
As for the deanonymization attack, I think it is pretty novel in that it uses a custom traffic signature to make the attack from http://freehaven.net/anonbib/cache/hs-attack06.pdf more reliable, but otherwise that is why we introduced guard nodes.
I'm still pretty sure this only makes people more secure in theory; the basis appears to be that instead of connecting to a random node every time a circuit is built, you instead connect to only one entry/guard node for 30-60 days. I think on paper that reduces the probability, but it seems to presume an attacker that doesn't modify their attack and doesn't appear to account for a keyspace of sorts that has reduced by over 50% and the introduction of a "touch me here" flag that says you're not only a relay, but you're guaranteed to be an entry point relay.
Looking at the numbers from a snapshot a few days ago: 839 exits, 865 guards, 1676 generic relays.
Previously for entry you'd be looking at a 'keyspace' of n/(839+865+1676), with the obvious problem that connecting to them at random every time you create a circuit is going to increase the probability that you hop through a compromised node. However, you need a fairly large value of N to make that realistic, I think the number cited was approaching 50%, but I could be remembering that incorrectly.
Now, you're at 865 _guaranteed_ entry points, which automatically reduces the required value for N and increases the value of each rogue node that gains the guard flag, which appears to be strictly based on bandwidth and stability. I'm hardly an expert on math or probability, but it seems like the 'weight' so to speak of a compromised node was never increased to account for the reduced number of nodes or guarantee that being a guard will always yield entry point traffic, which is to say that N is actually going to be some value multiplied by N instead of just N/C^2, (N*nWeight/C or possibly even N^nWeight/C). It at least seems like the probabilities were only worked for the state the network was in, and not for the state/behavior of the network after the modifications. So now you have a network where one can setup two boxes that are fast and stable and be guaranteed to receive exit and entry traffic and only needing about half as many boxes to reach the same 50% mark as before.
The math behind this concept is not overly compelling or I'm just dumb, both are probable and neither are mutually exclusive, but if I were looking for a state-based backdoor, I'd imagine it to look a bit like this (which is not to imply that is the case here by any means).
Jon
On Thu, May 23, 2013 at 11:35 PM, tor-dev-request@lists.torproject.org wrote:
Send tor-dev mailing list submissions to tor-dev@lists.torproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev or, via email, send a message with subject or body 'help' to tor-dev-request@lists.torproject.org
You can reach the person managing the list at tor-dev-owner@lists.torproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-dev digest..."
Today's Topics:
- Hidden services performance (Petter Solberg)
- Re: Hidden services performance (Jeroen Massar)
- Chrome browser and sand boxing. (Andrew F)
- Re: Chrome browser and sand boxing. (Andrew Lewman)
- Re: Chrome browser and sand boxing. (Andrew F)
- "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" (Tom Ritter)
- Re: "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" (Mike Perry)
- Re: "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization" (Nick Mathewson)
Message: 1 Date: Thu, 23 May 2013 14:46:12 +0200 From: Petter Solberg pettersolberg88@gmail.com To: tor-dev@lists.torproject.org Subject: [tor-dev] Hidden services performance Message-ID: CAPnamRP==01+HkQQWbg_mQv0uF=f3hK02jvffXDJBW8UfyMueQ@mail.gmail.com Content-Type: text/plain; charset="iso-8859-1"
Hi.
We are two master thesis students at the Norwegian University of Science and Technology (NTNU) which is looking into the performance of hidden services. We have already set up 19 physical Linux servers connected by gigabit Ethernet to be able to benchmark hidden services in a private tor network. We have also some public servers that we plan to utilize ( https://atlas.torproject.org/#search/disasterTor ). This mail is to inform you of our work and a request for ideas in where some bottlenecks are and if someone have done some previous research before.
Without any modifications to Tor we have been able to have a throughput of 180Mb/s through a single hidden service.
If you have some Ideas or a comment. Please reply.
Regards
Petter Solberg (pettso AT stud.ntnu.no ) & Bram Bezem ( bezem AT stud.ntnu.mo )
On Fri, May 24, 2013 at 12:32:20AM -0400, Jon Smithe wrote:
Hi,
As for the deanonymization attack, I think it is pretty novel in that it uses a custom traffic signature to make the attack from http://freehaven.net/anonbib/cache/hs-attack06.pdf more reliable, but otherwise that is why we introduced guard nodes.
The math behind this concept is not overly compelling or I'm just dumb, both are probable and neither are mutually exclusive, but if I were looking for a state-based backdoor, I'd imagine it to look a bit like this (which is not to imply that is the case here by any means).
Jon
Hi Jon!
You make some interesting and valid points, however this is the type of statement that spreads fud and it doesn't help anyone. Please see bug #8240 [0] which contains a detailed discussion of this topic.
tl;dr This is being worked on, 0.2.4 addresses many of these problems and 0.2.5 will continue to make improvments.
Whether or not you were implying this situation was a calculated decision that resulted in a "state-based backdoor", it is the insinuation of such a thing that can hurt Tor's reputation.
- Matt
-
Jon Smithe -
Matthew Finkel