Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 328
    • Issues 328
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 31
    • Merge requests 31
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #11207
Closed (moved) (moved)
Open
Issue created Mar 15, 2014 by Nick Mathewson@nickm🌻Owner

Sybil selection should be trickier to game

In response to some of the hidden service attack papers from 2013, we made it harder to use sybil-based tricks to move around the HSDir hash ring. But really, we should come up with a better way to shut down sybil-based tricks in general, in case there are more that we don't know about.

One place to start would be with the question: how often does the sybil code actually get invoked for legit nodes not run by security researchers? If the answer is "infrequently" , then perhaps we could move to an even simpler, blunter approach of "Call all nodes on an IP down for as long as there are too many verified-connectable nodes on that IP."

Or we might take another approach to selecting which nodes to list. legacy/trac#8710 (moved) isn't right, but perhaps something else might be.

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