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