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 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging