[messaging] Thoughts on reliability-optimized Mixnets

[Vincent Breitmoser]

Hey folks,

I had a discussion today with Trevor about Mixnets earlier today. We
gathered a couple of observations that I felt are worth sharing:

There are a ton of variables in mixnet design and configuration that can
be tuned to achieve different tradeoffs in terms of reliability,
performance, delay, and anonymity.  Some of those are amount of cover
traffic, delays, amount of mixes, mix topology, and so on. I'll be
assuming loopix-style decryption mixnets here.

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.

(Note that a provider-centered concept offers no anonymity to its users
whatsoever - the user does connect to them with their IP. This is only
about reducing the metadata footprint of exchanged messages between
users)

Even with a small number of mixes in a route, the reliability and
performance that each provider can achieve for their customers is
limited by the least reliable or performant of all involved mix
operators. Obviously, the only way for a mixnet provider to avoid
depending on another organization's operational performance is to run
all mixes itself. 

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? 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 think this is a a more legit approach than it appears at first glance,
particularly for a messenger that already has an established userbase -
think Whatsapp E2E rollout. Similar to how having E2E reduces some of
the "data responsibility" from the provider, running a mixnet might
reduce metadata responsibility.

 - V