More appropriate for tech. More comments below. On Tuesday 15 Feb 2011 17:10:18 mark wrote: > A high level and somewhat naive approach to this complex topic... > > First, what's anonymity in our context? > It means exchanging information without anyone knowing who it is who is > sending and requesting said information. > > The principle idea how to achieve this is to use an intermediary who > sends and receives information on your behalf. That way the other end > never knows your identity. Even a plain http proxy does that. > > But we haven't solved anonymity yet. We only shifted the problem to the > "anonymity provider", our messenger. He knows our identity and so does > everyone who compromises him. The anonymity provider can make it > "harder" (for others...) to be compromised by using cryptography, not > storing logs, being located in several offshore locations and by > relaying traffic over multiple servers internally that all needed to be > compromised in order to retrace the information back to "you". > > But that's still not good enough. We'd need to place all eggs in one > basket and trust a stranger, his integrity and security. We can do better. > > So we use multiple intermediaries. No single one of them alone > (and thereby no one who compromised one of them) can correlate > information that is relayed over them back to our identity. > > But while it looks like we solved the problem things actually got a lot > more complicated. Now we trust in a "network" of strangers. The > "network" knows our identity and so does everyone who compromises the > network. > Since our "messengers" aren't real people a single adversary can pretend > to be many messengers. He doesn't even have to control the > majority of all peers to pose a serious threat to the anonymity of everyone. > > There are further problems, some so called "decentralised" networks in > fact rely on centralised bootstrapping. We not only have to trust the > "network", in addition we have to trust a single central authority. If > that part gets compromised our anonymity is broken. > > Finally there are attacks from "the outside". An attacker doesn't have > to compromise anyone if he can track the messages simply by watching the > communication between "you" and the messengers. This generally does > apply to all mentioned approaches and only depends on their specific > implementations (encryption, padding, multiplexing, latency...) > > But the fundamental flaw shared by all of them is that they are based on > the assumption that we trust someone whom we actually don't trust. > > By definition anonymity in this context needs a third party. Further > this implies that we need to trust this third party with our identity. > We need trust because we can't verify anonymity. > (Compare that to privacy where all that's needed is Alice and Bob and > cryptography can offer mathematical verifiability - to some extents) > > The only way to solve the dilemma is to make sure that we only have to > trust people we already trust. We must trust them that they are indeed > different real persons, that they aren't colluding and that it's > difficult to compromise all of them without being tipped off. > > In other words, the only sensible approach to strong anonymity is a > fully decentralised darknet. Anything else is flawed by design and can't > ever be fixed, no matter what feature you bolt on. Concrete > implementations of darknets today have a range of weaknesses but those > aren't inherent and can be fixed. > > There is another, quite different approach to anonymity/pseudonymity. > Instead of using middlemen you could yourself pretend to be someone else > by disguising your identifying features. > You wouldn't have to trust anybody. However, for obvious reasons, this > isn't a concept worth further pursuing. > But it's an important argument whenever the idea of strong anonymity is > attacked with arguments like: "But you are helping the <insert > bogeyman>". They already have the means for conceptually even stronger > anonymity as they probably don't care about the illegality and > collateral damage of their methods. > > Would you agree with this analysis? I'd be very interested in your > comments and criticism. Are there any other fundamental concepts to > "solve" anonymity?
Seems a reasonable analysis. Explains some of the difficulties with mixnets: Most notably peer selection, if the bad guys can strongly influence peer selection they can bust you even though in theory to break the onion you need to compromise all the nodes involved. There are some other factors here though: Freenet isn't a mixnet. By the standard mixnet-favouring cyberpunk measurements, Freenet isn't all that strongly anonymous (but mixnets do have problems of their own, as you alluded to). Tracing users on Freenet is relatively easy if you can connect to everyone (which is obviously not possible on darknet), and more or less feasible if you can move around on the network and recognise large amounts of content (the first condition is expensive on darknet but cheap on opennet, the second condition is true if somebody is very chatty, inserts big files as CHKs or reinserts files). Freenet values unblockability and censorship resistance as well as anonymity. Mixnets don't store data; Freenet stores data. This actually prevents some attacks e.g. most uptime intersection attacks. I have posted some ideas on devl for using mixnets for the top SSK blocks to mitigate the second attack I mentioned (based on Ian's work). This involves routing through strangers, but should be somewhat safer as long as routing/topology/swapping isn't too hopelessly broken. Most of the traffic analysis related issues, and a lot of classic mixnet attacks, can be avoided if you don't care too much about latency. Given that publishers are generally in far more danger than readers, and given that latency usually doesn't matter so much on publishing, this allows some very interesting options.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ chat mailing list chat@freenetproject.org Archived: http://news.gmane.org/gmane.network.freenet.general Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat Or mailto:chat-requ...@freenetproject.org?subject=unsubscribe
