[tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,        |  Actual Points:
  padding, 041-proposed                          |
Parent ID:  #28632                               |         Points:  8
 Reviewer:  mikeperry                            |        Sponsor:
                                                 |  Sponsor2
-------------------------------------------------+-------------------------
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:21 mikeperry]:
 > Ok, to summarize the above discussion and the plan related to child
 tickets, here's what I think we should do for forward progress:
 >
 > 1. #define CIRCPAD_STATE_OBFUSCATE_CIRC_SETUP CIRCPAD_STATE_BURST
 >    and also change the one info log line that uses
 circpad_state_to_string() to use %d for state number instead (I think info
 lines don't need string names here, and it will simplify state re-naming
 for custom machines).
 > 2. Let's not make use of the reduced_padding flag from #29203 until we
 measure true overhead, as you say.
 > 3. Let's keep the safety check for no tokens left in
 circpad_machine_schedule_padding(), but let's remove the burst->burst
 transition in the rend machine that might have required it.
 > 4. In addition to the "two infinity bin" hack in the origin side intro
 circuit machine, let's *also* have no tokens in the INFINITY-1 bin slot,
 so that only CIRCPAD_DELAY_INFINITE can ever get chosen by that machine
 (unless we can think of a cleaner way to do this).
 > 5. Let's remove usage of should_negotiate_end.
 > 6. Let's always use CIRCPAD_TOKEN_REMOVAL_NONE (and never
 use_rtt_estimate), so I can write a version of #29085 that does not cause
 us to call monotime when these modes are used (so we don't have to worry
 about that overhead for these machines). If you want to add a
 CIRCPAD_DIST_FIXED that always returns the value of param1 for use as a
 length_dist, that might be the cleanest way to avoid token removal for 1
 token (rather than making a hacky use of CIRCPAD_DIST_UNIFORM to return
 rand(1,1)).
 >
 > I will work on #28780 and #29085 this week under the above assumptions.
 Can you take care of the above for the machines in this ticket? (Note the
 above items are not ordered in any kind of importance or priority nor am I
 trying to make binding decrees; I'm just trying to summarize. In
 particular: the state naming thing is not as important as the others and
 it if it is annoying and time consuming or you disagree, just skip it).

 OK! Here is a branch that does all the above (I think):
 https://github.com/torproject/tor/pull/1008

 It seems to work well in my chutney testing. I will pass it to alex so
 that I can also test it on his relay!

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