Hi Andreas, On Saturday 18 March 2017 10:06 AM, Andreas Krey wrote: > As an adversary, I wouldn't take down the bridge but either monitor > the traffic to it ($country can also do this on its border gateways), > or modify it to tell me the connecting IP addresses. Absolutely correct. In fact I mentioned this toward the end of the proposal. >> Or even better, why would the adversary need that random value >> when she can simply log all network connections coming into the >> (compromised) system? But I think that our users don't expect us to profile them. So, I believe it is bad practice to keep a list of something as important as IP addresses for any anonymity system. But there's a thing to be happy about. If we replace the list of IP addresses with something better, we might be able to prevent adversary from getting the knowledge of IP addresses that connected in the past. Suppose an adversary(lets say the government) suspects someone used a bridge to connect to Tor Network. They would only be able to know that for sure if they log that activity there and then. Means, they would not be able to de-anonymize users retrospectively. Of course, if the user again connects from the same IP and the adversary is monitoring the relay/bridge, that might cause problem. > End users tend to be on dynamic IP address, so stored IP addresses > aren't of much worth when you don't know when they were used; that > is a reason why $adversary might be more interested in snooping > than in compromising the bridge. > > (Although I don't know how prevalent changing IP addresses still > are when you're online permanently. E.g. here in germany telekom > changes to all-ip, and there no longer disconnects after 24h, and > thus you don't change IPs every day.) > > ... >> present in the set. The feature of this bitmap is that collisions could >> happen. And this collision creates deniability. When collisions happen, > > The problem is that for the accounting purposes you don't want (too > many) collisions, and also that state agencies don't necessarily > care for plausible deniability - if an IP address is found by > enumeration and probing the bloom filter they might still decide > to put that user on closer watch. (I've heard that a lot of the > traditional telephone tapping isn't used as evidence in court > but produces leads to where to investigate next.) > > On the other hand side you can indeed keep the filter rather small > because one bridge doesn't get that many collisions, and you don't > need to make it anywhere as big as to avoid collision with 2^32 entries. > Could also be dynamically sized depending on the number of clients seen > - you need aging anyway, so the next table can have a different size. > I feel that this isn't a nice solution. Suppose you have 10 cells and 3 hash functions at the beginning. Later when inputs exceed a threshold, you increase the size of bloom filter to make it to 20 cells. Now those 3 hash functions would map to the whole range which means the inputs that were mapped to 10 cells would now map to something completely different. Hence, error rate would be, I guess exactly 100%. > You can also go and poison the bloom filter with some random addresses, > even a lot, actually. If we're talking of 2000 users you can easily > throw in another 2000 random addresses without decreasing the > precision of the statistics much - only on a size comparable to > collisions in the bloom filter itself. > > - Andreas > Regards, Jaskaran
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev