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
  • #11743

Closed (moved)
Open
Opened May 05, 2014 by cypherpunks@cypherpunks

nodelist_add_microdesc: assign md to all appropriate nodes properly

Auths can to create the same md for two different relays. Because hash collision or evil relay. Last one can to announce any onion keys and family, without needs any proofs. All parts of code designed with assumption one md per many nodes, except nodelist_add_microdesc.

nodelist_add_microdesc using router_get_consensus_status_by_descriptor_digest which cut off digest, digestmap_set using SHA1 while md's digest about SHA256. nodelist_add_microdesc can't to assign md to all appropriate nodes, and only to first with id returned by router_get_consensus_status_by_descriptor_digest.

If evil relay will craft self id specifically then it will break usage of victim's relay for any freshly new clients till updated consensus (it's about several hours).

If to keep nodelist_add_microdesc with md per one node then md format need to be more unique generated. Unique md can be generated by adding ID of relay, it will stop crafted mds. Which way to choose? Need another ticket about it?

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