Re: [tor-talk] Tor (and other nets) probably screwed by Traffic Analysis by now

[Aymeric Vitte <vitteaymeric@xxxxxxxxx>]

Or the peers could randomely drop some packets, did not think strongly
about it for now, but why not


Le 03/06/2016 à 11:57, Aymeric Vitte a écrit :
>
>
>
> Le 03/06/2016 à 07:43, grarpamp a écrit :
>> On 6/2/16, Aymeric Vitte <vitteaymeric@xxxxxxxxx> top posted without trimming:
>>> Yes: https://github.com/Ayms/node-Tor#convergence
>>>
>>> Let's imagine that one Tor circuit reaches a P2P network (here browsers)
>>> and is splitted between different peers (UDP) circuits before
>>> reasynching to a relay or end point, then the reconciliation from the
>>> source to the end point is quite unlikely
>>>> Is there any group / list that is actively researching
>>>> or developing such networks? Or that wants to?
>> If I remember right you're doing file caching / serving
>> in the browsers-as-torrent-nodes layer. Yes that
>> asynchronous would seem to break end to end timing.
> Yes and different upload bandwidth of the peers make the timing
> correlation even more difficult
>> But the 654321012 byte file "into one tor circuit" from
>> user at one end would still count same bytes out to
>> a "reasynching end point" user at the other end.
>> (Or users plural if requested by more than one user).
>> Between otherwise relatively quiet endpoints / users.
>> If they are all shuffling around encrypted bits fulltime,
>> without being driven to do so by end user demand,
>> such that the start and stop of the bytes of the poster
>> and requestor[s] can't be delineated, that looks more
>> generally like the fill traffic.
> Here we could have some packets that are lost by the peers, because of
> UDP, because a peer left and broke a P2P Tor circuit, etc, then the
> packets must be resent and x bytes sent is then not equal to y bytes
> received, more generally it could be possible to send consciously
> several time the same packets who will be dropped by the reasynching
> end point, still x bytes sent will be equal to x bytes received at the
> end point but not further, that's one of the topics of the project, to
> be studied...
> -- 
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk