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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 asn):

 Replying to [comment:19 mikeperry]:
 > Some minor comments on the PR for the code and the spec.
 >

 Thanks for the review!

 > High level questions+comments:
 >
 > 1. Should we #define CIRCPAD_STATE_SPOOF_GENERAL CIRCPAD_STATE_BURST,
 and use a different terminology (and variables) for that first state? I
 think using the wtf-pad names can be confusing, since we're not using the
 histograms in the same way it did.

 I agree that the `BURST` and `GAP` state names are kinda random right now.
 There is also the question of how `circpad_state_to_string()` should work
 in case we rename them.

 Perhaps for these machines, we could have more specific names like
 `CIRCPAD_STATE_BURST` can become `CIRCPAD_STATE_OBFUSCATE_CIRC_SETUP`?
 `SPOOF_GENERAL` also seems like a decent generic name, but not sure what
 kind of machine would like that name, instead of defining their own.

 > 2. Should we flag these machines as reduced padding using #29203?

 Yes, that's a good question. Right now "reduced padding" is a very vague
 concept...

 Right now these machines are very low overhead at 15 padding cells in
 average, but perhaps we should not flag them as reduced padding until we
 learn what exactly reduced padding means by doing proper bandwidth
 overhead examinations.

 I'd like to do these examinations as part of my PhD research, so perhaps
 we can avoid markin them as such, and wait for the data? I don't think the
 world is gonna go crazy if we have to disable these machines in case we
 find that the bandwidth is too much.

 > 3. It's hard to follow force-pushed PRs like this. I personally would
 prefer a fresh PR squashed down rather than worrying about which version
 of the force-push I click on for a commit when doing the review.
 >

 Sorry about that. Will have that in mind for next time.

 > I can do the renaming of the burst state in the code and spec if we
 agree on a name for the first state of the intro and rend machines.

 Also replied to the comments on the PR.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs