[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_revision
 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
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Ok, to summarize the pad, and action 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.
 2. Not make use of the reduced_padding flag from #29203
 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 go (rather than making a
 hacky use of CIRCPAD_DIST_UNIFORM).

 If you can take care of those, I will work on #28780 and #29805.

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