Re: [tor-bugs] #5956 [Tor]: Thresholds of nodes to build circuits should be tunable and maybe consider weights too

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#5956: Thresholds of nodes to build circuits should be tunable and maybe consider
weights too
-------------------------------------------------------+--------------------
 Reporter:  nickm                                      |          Owner:  mikeperry         
     Type:  defect                                     |         Status:  needs_review      
 Priority:  critical                                   |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                                        |        Version:                    
 Keywords:  maybe-proposal tor-client MikePerry201301  |         Parent:  #5456             
   Points:                                             |   Actualpoints:                    
-------------------------------------------------------+--------------------

Comment(by nickm):

 Replying to [comment:21 andrea]:
 > Starting code review:
 > d602241687c771feb5d0344b5d5643039ac601c6: Looks correct to me; there is
 a typo ('decriptor') in comment for frac_nodes_with_decriptors(), though.
 > 86ee5a6bd15ef9f564eeeb1b723ef3ec101e579c: What's the '/* that's a bug
 actually. */' in count_usable_descriptors() about?

 Fixed in fixup! commits on that branch.

 > d602241687c771feb5d0344b5d5643039ac601c6:
 >
 > The calculation looks correct to me; the assumption that it's a
 straightforward product like that does depend on the path-usability
 function (i.e., a boolean-valued function of a path indicating if we can
 use it) is just a logical AND of analogous usability functions for each
 node, so all node-to-node links are permissible.  This will have to get
 rethought if we ever permit IPv6-only nodes.

 Right.

 > Observation: we base our belief in whether a node is usable for this
 purpose just on whether we get a descriptor.  If most of the entry points
 we have descriptors for are unreachable, what do we do?  Do we keep trying
 until we find one?  If a prospective censor went to the trouble of running
 a high-bandwidth middle node long enough for it to get the guard flag, and
 then blocked connections to most or all other nodes, could they force
 users in their network onto the entry of their choice and thus get the
 probability they can deanonymize down to linear in the fraction of exits
 they control?

 Good observation; that's not the attack this tries to stop, though.  If we
 can come up with a good defense/detection mechanism for that, we should
 have a design for it and try to build it.

 >
 > e23371bf55b2f880af8675e883b6f48876c18428:  How does
 min_paths_for_circs_pct get into the consensus for this?  Is making that
 work going to be a separate thing?

 AUthorities have a torrc option they can use to vote on things.

 > End code review.  I think this is okay to merge.

 Great; thanks!

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5956#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs