Thus spake Karsten Loesing (karsten.loesing@xxxxxxx): > Okay, here are the new results, this time with taking IP address changes > into account. The graph shows the fraction of random bridge subsets > (containing 3 bridges, 1 of them running on port 443) that had at least > 1 bridge running continuously throughout 6/24/48/96 hours. For example, > a value of 0.9 on the y axis means that 90% of all samples taken at the > date and time on the x axis were useful for another 6/24/48/96 hours. > > http://freehaven.net/~karsten/volatile/bridge-stability-ipchange-2010-04-01.png > > For comparison between the analysis with and without IP address changes, > here are the two 96 hours lines for both analyses. The red line in the > following graph is equivalent to the purple line in the previous graph. > > http://freehaven.net/~karsten/volatile/bridge-stability-96h-2010-04-01.png > > So, yes, when we take IP address changes into account, bridge stability > is worse than we thought from the first analysis. But still, it's not as > bad as one might have imagined. Note that the reasons for the drops on > December 11, 23, and 31 are probably problems with the bridge authority, > not with all bridges (I could make the analysis more precise by looking > at self-reported bridge uptimes, if required). That means that the 4 > days before those drops are probably too low in the graphs. In this > case, the 96 hours line is between 60% and 90%. Or to rephrase that, in > 3 out of 4 cases, people had a working bridge 4 days after requesting > bridge addresses, and the 4th person would have to request another set > of bridges. > > I'd like to hear what others say about these results. Am I missing > something? Is "3 out of 4" a horrible result? I don't know. I feel like there is a significant difference between: http://freehaven.net/~karsten/volatile/bridge-stability-4-bridges.png and http://freehaven.net/~karsten/volatile/bridge-stability-96h-2010-04-01.png I am especially suspicious as to why sets of 4 bridges weren't as dramatically affected by the bridge db failure? The big question on my mind is does it really cost us that much in terms of adversary effort to enumerate X% of the bridges if we hand out one extra? Can we run some simulations or math as to how many samples of 3, 4, or 5 bridges it would take for an adversary to get 50%, 60%, 70%, 80%, 90% blockage coverage of all of them? If the answer is that it doesn't significantly reduce the number of hits against https://bridges.tp.o that the adversary has to do to get 75% coverage, I think we should really consider handing out more to get that reliability boost. Also, reliability isn't the only issue here. We also should simulate blocking probability too, in conjunction with reliability. For example, what is the likelihood that all of your 3, 4 or 5 bridges from tp.o will be blocked or down if the adversary has 75% of the bridges blocked (or whatever the blockage rate was during the recent bridge blocking event in march). How much does this change if we hand out 4 or 5 bridges instead? There may be some sweet spot in that it takes the adversary less hits to block 75% of the network if we hand out 4 or 5 bridges, but it is also more likely for a user to still have at least one of their bridges not blocked and still running at this blockage rate. The best way to answer this is probably to get an estimate on the number of 3-bridge samples China needed to block the percentage of the network they blocked in March, and expect that they will devote this same effort in the future. Using this number of samples, does the likelihood of a user being blocked go up or down if China blocks an additional percentage of the network because we handed out an extra bridge, but they have an extra bridge IP or two to work with. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpZqPUy3CIrb.pgp
Description: PGP signature