Write simulator to evaluate security of Prop247 parameter choices

At Wilmington, we decided to write a simulator to evaluate the security of various parameter choices. We even made a pseudocode sketch of it. A picture of the pseudocode sketch is attached.

changed milestone to %Tor: unspecified

added component::core tor/tor guard-discovery-prop247-experiments milestone::Tor: unspecified priority::medium resolution::fixed severity::normal sponsor::V-can status::closed type::task labels

Trac:

Sketch of prop247 security simulator

Trac:
Keywords: guard-discovery deleted, guard-discovery-prop247-experiments added

Current state of simulator: https://github.com/asn-d6/vanguard_simulator

Some issues I've noticed:

1. guard.is_targeted should be updated every time we change guards in a higher layer
2. The graphs of G1 look suspicious (high CDF in low timescales for wimpy adversaries)
3. The "none" adversary still takes a long time. Can we have a mode of the sim that stops at guard discovery for particularly weak adversaries?

Replying to mikeperry:

Some issues I've noticed:

1. guard.is_targeted should be updated every time we change guards in a higher layer

Hmm, we are supposed to do this in self.is_targetted = self.is_targetted_func() when we instantiate a new guard node... Logic seems solid, but code might be broken. Will look more into this.

2. The graphs of G1 look suspicious (high CDF in low timescales for wimpy adversaries)

Hmm, I just pushed a commit that should improve the situation here. Now the CDFs look more close to what they should be. But there are probably more bugs!

FWIW, the probabilities of compromising a guard at the beginning of the run for topology 2-4-8 with medium sybil probability is: 0.1 for G1, 0.25 for G2 and 0.43 for G3

3. The "none" adversary still takes a long time. Can we have a mode of the sim that stops at guard discovery for particularly weak adversaries?

Still haven't done this one yet!

I also pushed a branch pypy in my github repo which maintains the pypy support through the recent commits, since it's actually super useful!!!

Replying to asn:

Replying to mikeperry:

Some issues I've noticed:

1. guard.is_targeted should be updated every time we change guards in a higher layer

Hmm, we are supposed to do this in self.is_targetted = self.is_targetted_func() when we instantiate a new guard node... Logic seems solid, but code might be broken. Will look more into this.

My point is that instantiation of the new guard node is insufficient to capture all line-of-sight events. Consider what happens to G1 if it was chosen as a guard while there were no adversaries in G2, but then an adversary node rotates into G2 later.

Though it does look like you do this update in adversary.guard_compromised(). I guess I missed that before.

2. The graphs of G1 look suspicious (high CDF in low timescales for wimpy adversaries)

Hmm, I just pushed a commit that should improve the situation here. Now the CDFs look more close to what they should be. But there are probably more bugs!

FWIW, the probabilities of compromising a guard at the beginning of the run for topology 2-4-8 with medium sybil probability is: 0.1 for G1, 0.25 for G2 and 0.43 for G3

This is better. 1-(1-c)^n gives 0.10, 0.26, and 0.45 for this config.

3. The "none" adversary still takes a long time. Can we have a mode of the sim that stops at guard discovery for particularly weak adversaries?

Still haven't done this one yet!

I also pushed a branch pypy in my github repo which maintains the pypy support through the recent commits, since it's actually super useful!!!

Yay!

This is done. See https://github.com/asn-d6/vanguard_simulator/wiki/Optimizing-vanguard-topologies for results.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed

moved to tpo/core/tor#23978 (closed)