[messaging] Thoughts on reliability-optimized Mixnets
moritz at headstrong.de
Sat Dec 30 18:33:08 PST 2017
On 31.12.2017 02:18, Vincent Breitmoser wrote:
> Research papers typically select these variables to have very strong
> anonymity guarantees. But it might be worthwhile exploring (or at least
> brainstorming) the opposite approach: Optimize for the least impact on
> usability, reliability, and performance, and see if we can still get
> worthwhile anonymity gains.
I would first like to see any actual formulas. It irritates me to even
begin to think about tradeoffs before we know what they might be in the
> Obviously, the only way for a mixnet provider to avoid
> depending on another organization's operational performance is to run
> all mixes itself.
The Internet depends on "other organization's operational performance"
all the time. Constantly. It is the Internet, after all. So, you put
reliability on top of unreliable networks, and that can give you certain
guarantees, regardless of who operates parts of it.
> Now this leads to an interesting legal question: How difficult is it,
> for some entity (that is generally honest), to create an organizational
> structure that operates mixes, under different jurisdictions?
As long as you exercise control (and that control can be constructed to
even just be "you write the software for your 'own' network"), that is
just too weak for anything serious. The type of legal attacks we're
already looking at is no fun, and I don't expect this to become
better... Look at what happened to the mix cascade run by the TU
Dresden, due to legal pressure. 
But yes, probably this could be done in a way that is less
straightforward to attack. If this is what people need to hear to
finally support this kind of research, then OK, I'm willing to agree
with the "better than nothing" argument, especially since it does not
change anything for me in terms of design, priorities, and required work.
It just sounds a lot more realistic to have a court sign some order for
"one bad actor (plus all subsidiaries under its control)" than for 10
legally independent parties.
> This seems
> like it's too easy - but what's to prevent three nominally independent
> mix service providers from running a mixnet, for some umbrella org?
I really do not see a problem with participating providers to actually
participate, and for some of them to provide decent bandwidth. We need
one mix operator to be honest, and depending on your exact architecture
you can get away with a total of three.
Compare this with Tor, where you not only need hundreds or thousands of
relays, you also need operators who can deal with hundreds of abuse
complaints per day. Which you simply won't have in a closed messenger
Overall, I see fifty other things that I would prioritize, and that
needs to be either developed or researched, regardless of who will
eventually run the network. Maybe that is not enough motivation, but
really, I don't see the big problem with mixnet operations spread across
multiple entities. Usenet does it, and how many PBs are transported
there daily nowadays?
Just to give you an idea, a non-profit IX in Berlin is sponsoring us
10Gbit/s of actual traffic, just like that. This is happening at more
and more places, thanks to the Tor relay community, and together with
the "no abuse problems" argument, it will be fairly easy to find even
faster, stable sponsored sites.
What's the figures we are looking at for zcash transactions? Signal
messages? Whatsapp? What would that mean for a mixnet?
Generally, it seems that practitioners are underestimating how much
actual research this topic still needs before we should put a mixnet in
front of any actual users. Until we have that research, we should use
the momentum to support them, make it easy to run simulations and
experiments, and once we have anything that resembles an interesting
research project we have more than enough universities already who would
love to participate in a large testbed.
There are dozens of interesting mixnet designs, and there is no (in
numbers: zero, none) framework that allows researchers to actually test
their hypotheses. We have the opportunity here to give them the right
tools, which also deals with real-world network issues and everything
else that is usually out of scope (PKI etc).
More information about the Messaging