[messaging] Thoughts on reliability-optimized Mixnets

[dawuud]

On Sun, Dec 31, 2017 at 02:18:48AM +0100, Vincent Breitmoser wrote:
> Hey folks,

Howdy.

> 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.

Actually most research papers do not even have complete statistical models with
which to reason about the entire mix network... merely focusing on some
smaller aspects.

Regardless of weather you want to optimize for usability or entropy,
there needs to be a statistical model that allows us to measure the
amount of information leakage and or the amount of entropy in the
system. So... from my perspective the work is essentially the same no
matter what you want to optimize for: Create a stats model and then
plug in a bunch of variables, calculate mix entropy etc.

> (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)

Indeed the Loopix Anonymity System is not actually an anonymity system
in the sense that most people would expect given the name. But as we've
discussed, there can be various designs very similar to Loopix
that offer sender anonymity and receiver anonymity with very little code
changes. There's lots of cool mixnet stuff we aren't yet doing. We will
when it's time. I like to write code once we have a specification.
If the specification is good enough the code writes itself.

> 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

Correct.

> operators. Obviously, the only way for a mixnet provider to avoid
> depending on another organization's operational performance is to run
> all mixes itself. 

This is not an option because it violates the core design principles
of mix network design: having all the network nodes be operated by
a single entity gives that entity too much power. If the operators
becomes a bad actor or receives a national security letter then
the security properties of the system can be broken.

> 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?

Nominally independent operators sounds good. The point is to have
multiple security domains in every route through the mix network.

Optimizing for legal jurisdictions should be low priority right now
compared to all the other considerations... especially given that
the compulsion attack need not obey any laws.

> 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.

Can you elaborate what you mean by this? E2E what?
Having end to end reliability is the only way to have reliability. There is no
way the interior of a mix network can ever offer meaningful reliability.
This is a core design principle of the internet, the end to end principle.

Reliability comes from the ARQ not the short delays.
Quality of services is latency + reliability.


Cheers,
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171231/3ad50e6e/attachment.sig>