Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #33325

Closed (moved)
(moved)
Open
Created Feb 13, 2020 by Gaba@gaba☀

O2.3 Implement static guard node support for OnionPerf.

Tor clients generally make three-hop circuits (that is, paths that go through three relays). The first position in the path called the guard node and is always chosen as the first hop for a fixed period of time. Using static guard nodes help protect against a certain kind of anonymity-breaking attack. The long-running OnionPerf instances that are currently deployed do not implement this mitigation because choosing a static guard at setup time would heavily influence their measured performance. Instead, they’re configured not to choose a guard for each measurement. We want to be able to measure the effects of good, bad, or average guards and compare the results, which is not possible without the opportunity to select a static guard node for an OnionPerf instance. Implementing the option to use a static guard in future OnionPerf instances will allow us to measure Tor performance closer to how clients experience it.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking