[tor-bugs] #31788 [Core Tor/Tor]: Circuit padding trace simulator

[Tor Bug Tracker & Wiki]

#31788: Circuit padding trace simulator
-----------------------------------------------+------------------------
 Reporter:  mikeperry                          |          Owner:  (none)
     Type:  enhancement                        |         Status:  new
 Priority:  Medium                             |      Milestone:
Component:  Core Tor/Tor                       |        Version:
 Severity:  Normal                             |     Resolution:
 Keywords:  circpad-researchers-want, wtf-pad  |  Actual Points:
Parent ID:                                     |         Points:
 Reviewer:                                     |        Sponsor:
-----------------------------------------------+------------------------

Comment (by mikeperry):

 Replying to [comment:3 pulls]:
 > The implementation now requires a client and relay trace (got a lazy
 python script to simulate a relay trace from a client trace as well). My
 biggest gripe right now is time. Every time a client/relay machine
 triggers padding, a corresponding event has to be added to the
 relay/client trace with an estimated time. This estimate will always be,
 well, wrong. I'm not sure it's possible to make this estimate in such a
 way that it'll fool time-based classifiers, even if we add in guard traces
 for better estimates and patches as you mention Mike.

 To be clear: I believe this simulator will only be accurate enough to do
 preliminary tuning of defenses against attacks, especially for expensive
 classifiers. I think final attack and defense evaluation, and possibly
 even some final tuning, should be done on the live network. At least until
 we discover that for all of our tested attack+defense combinations, the
 live network and the simulator agree.

 What do you mean by "wrong" though? We should try to make the simulator as
 close as possible. We are aware of the circuitmux problem, as well as
 delay introduced by libevent callbacks. These are both paths we hope we
 can optimize, though. Are there others?

 > Right now I think it might be best as a starting point to just try to
 use the simulator to find optimal machines against attacks like Deep
 Fingerprinting that ignores time. Once we have a better understanding of
 how feasible and costly that is we can look more closely at how time
 changes things.

 Do you mean ignores the time deltas between the client/middles and the
 guard?

 > Any thoughts on this? Have I missed some other reason than time
 estimates for including guard traces?

 Well, I have always assumed that the most realistic adversary for these
 attacks is one that runs them from inside the Tor network, where they have
 much higher resolution over circuit construction and usage, and have full
 circuit multiplexing information.

 We can simulate such an adversary by looking at client traces, or guard
 TLS traces, I suppose.

 > Also, if some other researcher working on this wants to collaborate
 please reach out.

 I now have some time to help with this a bit for the next couple weeks.
 Can you put your work in a branch on github?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31788#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online