wiki:org/meetings/2015WinterDevMeeting/Notes/GuardPriorities

Guards session notes

George is chairing the session.

Single Guard Node (Proposal: 236)

Parts of this proposal have been implemented.

  1. Increased bandwidth (Make the drop when becoming a guard less noticable)
  2. Increase lifetime (Increase the lifetime of a guard for a client)
  3. Guard fraction (Proposal to leta guard become a "100%" guard over time, rather than instantaneously)
  4. Reduce from three to 1 (Use only one guard rather than three: DONE)
  5. DirAuth change required (Should show the guard fraction)

Sniper Attack (Proposal: 241)

By taking out specific guards, adversaries can hope that a client will eventually pick their guard. Reducing the number of guards made the chance of doing an attacker becoming someone's guard a bit lower.

The problem is that, currently, the user cannot notice this so called "guard sniping". We need to think of a proper way to notify the user that his or her guard nodes are quickly and rapidly becoming unreachable. (Having three guards suffers from the same problem)

Nick had a proposal to limit the amount of "cycling" of guards that can happen. This comes in the form of two different limits:

  • Don't connect to too many guards in a given timeframe
  • Don't insert too many guards in a given timeframe

We are wondering if this should be a soft or a hard limit and what action should be taken:

  • Notify the user
  • Stop operating

We should probably also collect/keep/show statistics about how many guards have been tried or cycled in the past.

Before we can enforce the limits, there is an issue that needs fixing: the guard "datastructures" and logic doesn't seem to perform too well and there are some weird issues.

Guard Data structure issues

  • Certain behaviour can lead to getting way more guards than you actually need (they stay in the datastructure, and you only get the last one) [ Ticket #12595 ]

Guard fingerprinting

If a client is using a single guard (or worse, multiple), fingerprinting is possible (linkability issue). For example, a user using a guard node from various places might reveal the location of the user, as there might not be too many users using the same guard close to the user.

Guard discovery attacks

Finding hidden services by taking out the guards of the hidden service.

Increasing the lifetime of a guard in this particular instance will give the adversary more time.

Middle relay pinning might help.

Pad latency

Injecting latency may help thwarting timing attacks

Extra directory guards

We might want to use more directory guards to prevent getting too little (or poor) relay information to build circuits.

Last modified 4 years ago Last modified on Mar 5, 2015, 11:00:40 AM