[tor-dev] Can we stop sanitizing nicknames in bridge descriptors?

[Karsten Loesing]

On 6/4/12 7:43 PM, Sebastian G. <bastik.tor> wrote:
> Karsten Loesing:
>> On 5/16/12 8:47 AM, Karsten Loesing wrote:
>>> On 5/2/12 2:30 PM, Karsten Loesing wrote:
>>>> If nobody objects within the next, say, two weeks, I'm going to make an
>>>> old tarball from 2008 available with original nicknames.  And if nobody
>>>> screams, I'll provide the remaining tarballs containing original
>>>> nicknames another two weeks later.
>>>
>>> Here we go.  These are the sanitized bridge descriptors from May 2008
>>> including original bridge nicknames:
>>>
>>> http://freehaven.net/~karsten/volatile/bridges-2008-05-nicknames.tar.bz2
>>
>> And now, two weeks later, here are the sanitized bridge descriptors
>> containing nicknames:
>>
>> https://metrics.torproject.org/data.html#bridgedesc
>>
>> Best,
>> Karsten
> 
> Here are my findings for the tarballs of March 2012. I could pick freely
> from any 2012 tarball. I picked March 2012 because it contained the
> "bridge peak" and the relays seemed stable.

Results are that 205 of your 308 guesses (66%) were correct in the sense
that a bridge was at least once running in the same /24 as the relay
with similar nickname.  At any time in March 2012, you'd have located
between 26 and 46 bridges (1.7% to 3.3%) with 37 bridges (2.5%) in the
mean via nickname similarity.

Your accuracy went up from 30% in your May 2008 analysis to 66%, but the
overall fraction of bridges you'd have located went down from 10% to
2.5% in the mean.

I think we can live with an adversary being able to locate 1 out of 40
bridges if the operator assigns a similar nickname and runs it on a
nearby IP address.

If you think you can come up with a vastly improved rate of located
bridges of, say, 5% or more, I can look at another findings.txt of yours
for a different month than March 2012.

If not, let's conclude this analysis and assume that publishing bridge
nicknames is safe enough---until somebody shows us that we're wrong.

Again, thanks for running this analysis!

Thanks,
Karsten