[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Question for those who say "Tor is pwned"



Thanks, will keep this in mind

The question was the one in the link provided below regarding potential
research exploring some ways to defeat trafic correlation splitting the
Tor circuits (maybe somewhere similar to your semi-synchronous concept)


Le 21/06/2016 Ã 18:48, Paul Syverson a Ãcrit :
> On Tue, Jun 21, 2016 at 01:28:12PM +0200, Aymeric Vitte wrote:
>>
>> Le 21/06/2016 Ã 06:19, Paul Syverson a Ãcrit :
>>> We published a design in 2010 that essentially turns a
>>> solution against a passive adversary into a solution against an active
>>> adversary. It had some nice theoretical properties, but I don't think
>>> it was practical. These haven't been ruled out. There is ongoing
>>> research, but so far none of it has looked adequately useful in practice.
>> Probably you are referring to the paper mentioned in
>> https://lists.torproject.org/pipermail/tor-talk/2016-June/041192.html
>> which indeed as I commented does not look realistic to implement, then I
>> suppose that the answer to my question is no
> Yes that paper. Not sure what the question is.
>
>>> I think there are some things we maybe could do with mixing and
>>> synchronization to raise the bar at least a little against a _passive_
>>> adversary. I have told many researchers my thoughts about this, but so
>>> far nobody has taken it up that I know of. I would like to look into
>>> it myself, but I already have a many-years backlog of more important
>>> (more likely to make a real difference IMO) research questions to
>>> answer.
>> Would be interested to know what are those thoughts (on or off the list)
>> and/or get possible links to them
> Well there's things like alpha-mixing (better tau-mixing) as that
> could be used to blend and improve security for traffic of different
> sensitivity levels _if_ it can adequately avoid leaking how
> paranoid/sensitive different traffic is. Various proposals following on
> those lines have been floated, but this needs a lot more analysis to
> see how/if it would make sense.
>
> Another thought I've raised to a bunch of people for at least 2-3
> years is the idea of semi-synchronous building of Tor circuits. Since
> most circuits are built pre-emptively it should be relatively easy to
> implement and shouldn't cost much in overhead if all relays, e.g.,
> batched and fulfilled all extension requests they received in the last
> say 2 seconds, effectively timed mixing of circuit building
> cells. This might make it hard for a widescale passive network
> observer to trivially identify circuits simply from the building (as
> Bauer et al. first explored at WPES 2007).  They would then have to go
> into the relayed traffic.
>
> Questions include, how much extra work does this really create for the
> adversary? (It doesn't appear to have much overhead, but if it has
> even less useful effect, it's not worth it.)  What to do when circuits
> are not available (Do you just say screw the delay for those, or bite
> that bullet which implies driving a nontrivial fraction of users to
> less secure options)? How often _are_ circuits not available
> pre-meptively? Does this somehow disproportionally affect a
> particularly sensitive class of traffic?  I'm assuming you don't want
> to actually synchronize relays here as I could imagine all kinds of
> weird congestion effects.  Even if you don't one should do lots of
> Shadow experiments or some such (after the prior questions make it
> seem worth doing them) to make sure these effects aren't induced
> anyway...
>
> aloha,
> Paul

-- 
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