Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #4862

Closed (moved)
Open
Opened Jan 07, 2012 by Arturo Filasto@art

Consider disabling dynamic intro point formula (numerology)

This ticket was repurposed and it's now about discussing the dynamic formula for determining the number of introduction points of a hidden service.

The formula leaks the popularity of the hidden service on an hourly basis. Furthermore, it's memoryless which causes the hidden service to use a much bigger number of introduction points than normal (comment:15:ticket:15513).


In #3825 (moved) rransom proposed to tune the number of IP to rebuilt once one expires based on the history of the Tor HS usage. I believe these numbers are not optimal and there should be a better way to do this.

These are the first numbers that I will try to estimate: I = number of intro points C = Connections made to an IP in it's lifetime T = Total number of connections made to the HS in 24 hours

What we are interested in estimating is the value of NUM_INTRO_POINTS_MAX and this is based on the estimation of C. To determine this we will consider this equation:

I = T/C

I believe it is reasonable to suppose that a very busy HS will at most have 1M connections in 24 hours. This means that:

I = 1'000'000/C

Currently C is set to 16384. I am not sure why this number was chosen, but if this number is good we would need to set the value of I to 61.

Lets take for granted that 61 is a good value for NUM_INTRO_POINTS_MAX, this means that the number of active IP at a given time should be in the range of 3-61.

For this reason I believe it would be good to have the number of IP to recreate to be in the range of 1-20 dependent on the history of a Tor HS.

The basic thing we can do is use a linear function to determine this number x. We want a linear function that has these properties:

f(0) = 1``f(4/3) = NUM_INTRO_POINTS_MAX ``(supposing that for lifetime of IP tends to end the fraction (time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT) -> 4/3) This leads us to this:

x = (1 - NUM_INTRO_POINTS_MAX)*((time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT)) + 1

in the case of NUM_INTRO_POINTS_MAX = 20 this means:

x = 25.3333333 * (time_since_publishing/IP_MIN_LT)*(accepted_ip_connection)/(IP_CON_LT) + 1

A better way to do this is have an exponential function that converges asymptotically to 20.

Does this seem sane?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.2.7.x-final
Milestone
Tor: 0.2.7.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#4862