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

["Sebastian G. <bastik.tor>" <bastik.tor@xxxxxxxxxxxxxx>]

Karsten Loesing, 03.05.2012 13:32:
> Hi Sebastian,
Hi Karsten,

>> Do similar names actually mean that bridges are located where the relay
>> is? (Apparently you've got the data to see these correlations)
> 
> A fine question.
> 
> How do we define "similar"

That's the same problem an attacker would have. I truly understand the
point. One can up with a naming scheme that's not in "the pattern", but
where it's still easy to correlate the name. e.g.  relay "Earth" and
bridge "Moon", relay "Jupiter" bridge "Callisto".

> and "located where the relay is?"

I guessed that would be defined already.

The safest way is to ensure that bridge and relay operators are aware of
the fact that their naming scheme should avoid correlations, wherever
both are actually located. The question here is on how to ensure it?!

> So, while we have the data to see these correlations, I think that
> whatever similarity algorithm we come up with, somebody else might come
> up with something smarter.  If we do the analysis you suggest and learn
> that it's safe to include nicknames, that doesn't say very much.  Only
> because we have the data to confirm how well our attack would works
> doesn't automatically mean we're in a good position to design the attack.

If I remember correctly Bruce Schneier "once" said that it's easy to
built/invent your own cipher which you are unable to break, but that you
can't be sure that no one else can.

> If you want to run this analysis with the 2008 tarball (assuming there
> won't be general objections within the next two weeks), I'm happy to
> take your list of likely bridge IP addresses and tell you how accurate
> your algorithm is.

I'll could flip a coin and it would be much more accurate than any
algorithm I could come up with.

I'm not able to use any mathematical function on the data. And I have no
"skill" to do that in a batch. I as an adversary would "crowdsource" the
similarity since humans might have a better understanding what might
belong together.

All I could do is look through the list manually and compare them with
the list of relays. I don't think I'm going to do this as I don't
believe that I'm going to find anything.

>> "We don't need it, so better remove it." I really like that.
> 
> I think we're really conservative with giving out bridge data, and
> that's good.

I agree.

> At the same time there's a value in giving out information about
> bridges, so that "remove everything" is not a good answer.  For example,
> I think if we give bridge operators better feedback how their bridge is
> doing, we'll suddenly have a lot more bridges.  Making it easy for
> bridge operators to use Atlas would be a good step into that direction.

I agree again. At least for interested operators it's very nice to have.

>  The same applies to funders who realize from our statistics how
> successful the Tor Cloud project is and who then want to fund it more to
> make it more usable, support more cloud providers, etc.

When it's helpful.

>>> And are we giving away anything else with the nicknames?
>>
>> Maybe it's location ;)
>>
>> As I read "hints on the location" for the first time; I though it would
>> mean that "TowerBridge" or "BridgeofLondon" would be bad since it could
>> hint to London.
> 
> Well, in that case you'd learn that there's a (Tor) bridge in London.
> But that wouldn't help you very much, would it?

That was my first misinterpretation of "hints on the location" as I read
it "back then" (some time ago). I tried and failed to understand what
one would get from knowing where are bridge would be located
(geographically). I think it does not hurt.

> Thanks for your input!

Probably it wasn't necessary at all. Don't think it was to useful either.

> Best,
> Karsten
Same to you!
Sebastian

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev