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

Closed (moved)
Open
Opened Nov 21, 2017 by teor@teor

compare_vote_rs() could check more fields for better SHA1 collision resistance

If someone submits descriptors with the same SHA1 hashes, compare_vote_rs() checks a few fields to make sure they are really the same.

We should make sure there is some way of checking all (most?) of the fields. And we should compare new fields when they are added to [vote_]routerstatus_t. But we can't just use a binary comparison, because some of the fields are pointers.

Do we need a new consensus method to add extra tie-breakers?

Here are the fields from vote_routerstatus_t and routerstatus_t, in rough order of size/flexibility/collision-usefulness:

Comparing these is probably necessary, they have 128+ bits of entropy:

  • version
  • protocols
  • exitsummary
  • ed25519_id
  • ipv6_addr

Comparing these might not be necessary, they only have a few bits:

  • ipv6_orport
  • measured_bw_kb / bandwidth_kb ?
  • guardfraction_percentage

I'm not sure if comparing these is necessary, they probably don't have enough bits to lead to a collision:

  • flags / is_x (x is a flag name)
  • supports_x (x is a feature name)
  • has_guardfraction
  • has_measured_bw
  • has_ed25519_listing
  • has_bandwidth
  • has_exitsummary

This is a bug in Tor 0.2.0.3-alpha, which introduced this tie-breaking code. (Or in all the versions since then that added extra fields to [vote_]routerstatus_t, but didn't add them to the tie-breakers.)

To upload designs, you'll need to enable LFS and have 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#24366