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

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu May 16 06:00:46 UTC 2019


#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, network-team-           |
  roadmap-2019-Q1Q2                              |
Parent ID:                                       |         Points:  8
 Reviewer:  mikeperry                            |        Sponsor:
                                                 |  Sponsor2
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Ok, so close! I fixed some things up and made a new pull request:
 https://github.com/torproject/tor/pull/1029

 Here's what I did:
 * Rebased a few times due to conflicts
 * Fixed the RTT log message (this message was due to our decision to
 switch to counting padding negotiation as non-padding earlier in this
 ticket)
 * Improved comments in the machines about the packet traces
 * After the RTT fix, I used chutney hs-v3 test to check packet patterns
 with https://github.com/asn-d6/padanalyzer to make sure I didn't break
 anything
 * Demoted some logs and ensured correct log domains.
 * Remove the log messages that https://github.com/asn-d6/padanalyzer needs
 (they should be info/debug level rather than warn, but demoting them would
 break padanalyzer anyway, so...)

 I am convinced that this branch functionally does what we want now.
 However, I think it would be useful to do the following:
 * It bothers me that the client and middle-relay states are in the same
 function for each machine. I would rather have each machine be in its own
 function, even if they are mostly (or even exactly) the same machine (not
 sure if this is heretical wrt code duplication, but I think code
 readability should trump that)
 * We *maybe* should find some way to write a unit or chutney test to
 ensure that future changes to circuit setup don't change out packet
 patterns (if these machines actually do survive a research cycle, then
 they risk being broken by things like my RTT fix)

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


More information about the tor-bugs mailing list