Tor, the pentagon's cyberweapon

Karl gmkarl at gmail.com
Wed Oct 14 20:09:58 PDT 2020


On Wed, Oct 14, 2020, 11:03 PM Karl <gmkarl at gmail.com> wrote:

>
>
> On Wed, Oct 14, 2020, 10:48 PM Peter Fairbrother <peter at tsto.co.uk> wrote:
>
>> On 14/10/2020 23:59, Karl wrote:
>> >
>> >
>> > On Wed, Oct 14, 2020, 6:34 PM Peter Fairbrother wrote:
>>
>> >     To put some BOTE numbers on that, suppose you want to provide for 1
>> >     million concurrent users. You have about 150 TB per month user
>> traffic
>> >     to play with (500 x 1TB, ~3 hops), 150 MB per month per user, or 450
>> >     Baud.
>> >
>> >
>> > Could you explain your math here?  How did 500TB/3 (am I wrong?) become
>> > 150MB?
>>
>> There are 500 raspberry pi's, each on the end of a 1TB/month link.
>> That's 500 TB/month total traffic, but dividing by 3 we get
>> approximately 150 TB/month user traffic.
>>
>
> How about more routers if there are more users?
>
>
>> With a million users at any time that's 150TB user traffic per month:
>> divided by 1 million users that's 150MB per user per month.
>>
>> As they are concurrent users (the total number of users is higher, but
>> at any time 1 million users are using the service) that is 150 million
>> bytes per month per user divided by 2,592,000 seconds per month, which
>> is 58 bytes per second per user or 463.32 baud.
>>
>>
>>
>> Looked at another way, if people always used an anonymity service the
>> hops would multiply their traffic by say 5 times (3 times as in TOR is
>> not enough). Covertraffic and file size
>
>
> I'm curious why you believe it to be not enough (two seems good enough to
> my quick guesses if traffic is constant, but I can't think worth beans);
> I'm happy to look at a reference.
>

I thought about this a bit, realised some strong danger of only two hops,
and realised that more hops are needed if an adversary is running many
nodes.  Brings ideas of blockchains, trust metrics, friend-to-friend
networks.

Bandwidth is /5.


> padding traffic would at least
>> double that, so we would need at least 10 times the normal traffic the
>> users created.
>>
>
> I propose constant rate: cover traffic reduces as legitimate traffic
> increases.  Would this work, do you think?
>
>
>> And you ned a lot of traffic through your anonymisation network to get
>> decent anonymity, you need a large anonymity set.
>>
>> Web traffic is expensive - making it at least ten times more expensive
>> is not on, especially if nine tenths of it has to be paid for by someone
>> else.
>>
>> That's not counting the servers etc - getting a pi to handle 386 kB/s
>> [1] of anonymity traffic is not trivial, I don't even think it is
>> possible.
>>
>
> Mmm might need good bare metal algorithms.  Easier to use the client
> device which has more CPU.
>
>
>> [...]
>>
>> > Enforcing TLS is much more reasonable nowadays.  (You could add a
>> plugin
>> > to use http tricks to hide file sizes.). Not what I would focus on once
>> > it gets nonsimple.
>>
>> A good proportion of TOR traffic will be protected by TLS anyway,
>> especially those sites which you might not want other people to know you
>> are accessing.
>>
>> Visible file sizes are the main anonymity weakness in TOR.
>>
>> If you suspect someone you compare the file sizes of the traffic through
>> their system with traffic through the exit nodes.
>>
>
> Wouldn't using chaff to make your transfer rate relatively constant close
> almost all of this anonymity attack surface?
>
>
>> In the UK at least it is legally fairly easy for the cops to demand that
>> info (and most ISPs are legally required to obtain and store that data
>> anyway) - getting everyone's traffic info where the cops have no suspect
>> is a little harder, but not impossible.
>>
>> Of course the ordinary cops don't use that power, and the people who do
>> use it don't want it known that they can do it, so you will find that
>> they make up stories about reused passwords and the like being the
>> source of their information.
>>
>>
>> Peter Fairbrother
>>
>> [1] 1TB/month divided by 2,592,000s/month
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6245 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20201014/2ef65ded/attachment.txt>


More information about the cypherpunks mailing list