Always select paths from back to front?
On #184 (closed), @mikeperry suggests that we should always pick paths in reverse order, from the last hop to the first. This prevents the following attack:
- The attacker makes us build a zillion circuits ending at a point they control.
- The attacker notices which exit(s) we never use.
- The attacker infers that our Guard must be in the family of those exits.
This attack gets worse when we have onion services, since they provide a mechanism for an attacker to force you into building a zillion circuits.
An implementation for #183 (closed) would be necessary in order to implement back-to-front path selection correctly.
But before we move ahead: There is a related information leak to consider, if we do implement this defense without changes to our guard selection algorithm:
- Usually we use primary guard A.
- But when our exit or middle is in the same family as A, we choose guard B instead. If guard A and guard B are ruled out, then we choose guard C.
- From our choice of primary guard, a local observer can infer information about our paths.
Perhaps the solution to that information leak is to increase the guard-n-primary-guards-to-use
parameter so that clients choose randomly among a few guards for each circuit, rather than trying to only use one? But changing that parameter would roll back the benefits of proposal 236. See also "One Fast Guard for Life".