Dishonest Tor relay math question - tor-talk is to lazy

[Peter Fairbrother]

On 09/10/2021 22:17, PrivacyArms wrote:
> What I want to know is the percentage risk of x malicious nodes to deanonymize a user by controlling the full circuit.

there isn't a simple answer, but you can work out a lower bound like this:

First, note that the actual nodes do not need to be dishonest, the 
attacker only needs to be able to get traffic data from the node's ISP 
or somewhere else in the 'net.

There are three nodes in use, but the middle node doesn't matter. You 
could have 20 nodes in between and they still wouldn't matter.

If both entry and exit nodes are traffic-compromised then the user can 
be deanonymised by traffic analysis in roughly one session. Here I am 
assuming sessions with say 10 blobs of traffic, which is low for eg an 
internet site visit.

Suppose 50% of nodes are traffic-compromised, then if a user makes one 
session the chances of compromise of the session are 1/4.

If the user makes 10 sessions then the probability of deanonymisation of 
one of those sessions is 94%.



Note that any modes in eg the UK or US are automatically 
traffic-compromised, because GCHQ and NSA can get traffic data for them 
without specific warrants (and a warrant for traffic data for a Tor node 
would be almost automatically granted anyway)..

Also any traffic which *goes through* the US or UK is traffic-compromised.


Peter Fairbrother

> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 8, 2021 7:35 AM, grarpamp <grarpamp at gmail.com> wrote:
> 
>>> How can I calculate how much impact X honest Tor relays have?
>>> Is it better to calculate with bandwidth consumed (250Gbps), despite the
>>> number of relays (~7000)?
>>> Basically, I want to get the mathematical equation to this statement:
>>> I run X Tor relays at Y Mb/s each and by doing so I secure Z % of the Tor
>>> network!
>>> Starting thoughts:
>>>
> 
>>> -   Each “normal” route has three nodes involved: Guard, Middle, Exit
>>> -   I am aware of guard pinning and vanguard protection for middle relay
>>>      pinning
>>>      
> 
>>> -   Maybe it is easier to assume an infinite usage time of the network to
>>>      eliminate guard and vanguard pinning
>>>      
> 
>>> -   I guess the best is to assume a scenario with 1%, 5%, 10%, etc. dishonest
>>>      relays
>>>      
> 
>>>
> 
>>> My take on this:
>>> Tor has approximately 7000 relays.
>>> If I consider a number of 5% malicious relays, this would be: 350
>>> My calculation:
>>> (1/(7000/350))(1/(7000/349))(1/(7000/348))
>>> = 0.000123931
>>> = 0.0123931%
>>
> 
>>> 1.  Is my approach correct?
>>
> 
>> Generically, assuming you're only running the
>> exit use case, not the HS onion case.
>>
> 
>> You'll probably want to consider some adjustments...
>>
> 
>> -   There's not 7k exits, only ~1k, but it's a ratio term
>>      so then it only matters if you're expecting different
>>      densities of bad/good across each of the guard/mid/exit roles.
>>      
> 
>> -   There's not 7k guards, only ... .
>> -   tor only uses family, /nn cidr blocks, etc once in a circuit...
>>      effect is not 7k nodes, but G groups made up of 1-N nodes.
>>      Read torspec, scrape consensus, determine the resultant
>>      number G that tor actually gives itself to choose from.
>>      
> 
>> -   Some nodes are down, sleeping, busy, filtered, etc.
>> -   Not all exits serve the clearnet ports you want.
>> -   Circuits expire, nodes rotate, etc.
>>
> 
>>> 2.  Not every relay has the same bandwidth. How could I change the
>>>      calculation to make it more realistic?
>>>      
> 
>>
> 
>> Read torspec, scrape consensus, determine how tor is
>> allocating clients across its bandwidth gravity well, etc.
>> See also...
>> https://metrics.torproject.org/
>>
> 
>>> 3.  How can I add the effect of guard fixation?
>>> 4.  How can I include the effect of mid-node fixation by the vanguard?
>>
> 
>> You didn't really define exactly what attack ("dishonesty")
>> you're trying to model, so these settings could render you
>> anywhere from safe, to having no effect and thus still being
>> subject to the exploit.
>>
> 
>> See also...
>> https://anonbib.freehaven.net/
>> https://git.torproject.org/torspec/
>