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 first place. > 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. [1] 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 scenario. 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). Moritz [1] https://anon.inf.tu-dresden.de/strafverfolgung/index_en.html _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
