Jason speeks

[tsafa1]

For those of you who do not know. Jason is the original disigner of Mute. In this thread I will pick out what i consider to be important and key aspects of Mute development and post them.

This particular response was in response to a speedy salution:

Ready to write code, sure. But without careful thought, your code:

1. Won't fix the problem that we're facing
2. Will bring the MUTE network to its knees by accidentally causing searches to flood the entire network.

You think that FORWARD trees, Utility Counters, DROP_CHAINS and all the rest just flew out of my fingers into code without any thought? The very existence of the UC document is what brought this particular anonymity weakness to light in the first place. Without that document, the chances of people like Gwren actually understanding how MUTE searches anonymously would be slim.

It took me *months* to come up with these solutions and to iron out the logical problems inherent in my initial ideas.

......................................

This is not the way to build a system that offers serious anonymity. We need to be able to prove to people that the system works. Once we have proofs in hand, we need to put them up for public review to make sure that they are correct *before* coding anything.

Also, just because something "seems to work" okay on a small test network does not mean it will scale well once it operates in a large network. In fact, simply sending every search to all neighbors will work fine in a 10-node network (that is exactly what WASTE does... even for chat messages). So, small scale beta tests of proposed solutions really don't tell us much about whether our solutions are "correct", since correct means both "anonymous" and "scalable". We need more than just coding and testing to come up with solutions that will work in large networks---we need pencil-and-paper scalability analysis, at least of loose worst-case bounds.

There are plenty of scalable search mechanisms (like TTLs) that are not anonymous. There are plenty of anonymous mechanisms (like "send to all, no matter what") that aren't scalable. The UC document, with all of its "academic fluff" (or whatever the pseudo-jargon in your comment below is meant to imply) is the foundation of a system that balances both anonymity and scalability in a way that can be analyzed. Good thing people like Gwren are reading that document (and hopefully the ideas there will help him improve his ANTs network).

Jason

So it seems that this will take a while to fix, but when it is fixed it will be done right.

[tsafa1]

Jason has a Proposed solution:

> I have updated the "utility counters" document to deal with
> multi-neighbor attacks. Dealing with these attacks involved quite a bit
> of thought, but the final solution is rather simple and elegant. The
> math, wherever it occurs, involves reasoning about worst-case
> scalability.
>
> The updated document is in its usual location:
> http://mute-net.sourceforge.net/utilityCounters.shtml
>
> The basic issue here (or the "hole" that Gwren pointed out) is that the
> original mechanisms were designed with only one attacker in mind. In
> other words, they would prevent one of your neighbors from figuring out
> what you were sharing. So, the "threat model" in the original document,
> though it was not explicitly stated, was one attacker node working alone.
>
> Gwren's attack involves two (or potentially more) neighbors working
> together. Of course, such an attack would be rather easy to mount (even
> for the technically-feeble RIAA), so the original threat model was not
> realistic.
>
> The new threat model is n-1 of your neighbors being potential attackers,
> where you have n neighbors. In addition, we want to handle the case of n
> neighbors that are all attackers as long as the attackers do not know
> that you only have n neighbors. Our defenses in these cases are all
> based on plausible deniability.
>
> Unfortunately, the threat model for MUTE has never been explicitly
> stated. Such a document is sorely needed.
>
> One sad casualty is the UC update mechanism: by including information
> about your result count and your neighbor count in the formula for
> updating the UC of a message, you give a group of coordinated attackers
> too much information. Thus, the mechanism has to be replaced with a more
> generic TTL mechanism (or, for implementation simplicity, new UC update
> parameters that make UCs behave like TTLs. In fact, you fix this
> yourself without any coding. In MUTE/settings, set
> utilityAlpha.ini to 0
> utilityBeta.ini to 0
> utilityGamma.ini to 1
>
> I describe this change as "sad" because the original UC update formula is
> the crux of a more scalable distributed search.
>
> Jason