> I meant: If you want Tor-like circuits, then you should contribute to > Tor itself. You don't want to fragment the anonymity set more than > necessary. It's different if you have some really new idea of course, > but new language, changing ciphers, etc. do not suffice.
If my understanding is correct, Tor is quite highly integrated and is serving very specific purpose. Because of different environment with different capabilities and different requirements it is quite difficult for me to use Tor directly as is. This is why I thought it might be useful to find a common ground one level below Tor and have a few different protocols like Tor on top of it, without re-implementing interfaces/properties that are common for many anonymous networks. Then we can describe other systems (including Tor) as specific combination of pluggable features that Ronion needs for functioning. Just like in most cases no one re-implements something as generic as TCP/IP stack. So I'd like to first discuss Ronion itself in order to identify whether it is good enough base to possibly implement what is required by Tor and/or mix networks on top of it. > In fact, there is a recent paper that bounds the anonymity as a roughly > a function of bandwidth * latency where bandwidth consists mostly of > cover traffic. https://eprint.iacr.org/2017/954 > It's more complex however because cover traffic and latency can take > different forms. As an example George Danezis has spoken recently about > tweaking reliability, which falls partially on both sides. > > Arguably, you cannot protect against traffic analysis at all in a > circuit based system like Tor anyways. And Tor does not do cover > traffic or delays for this reason. I'm actually leaning towards Tor's decision on this too, though, taking into account low bandwidth requirements in my case I'm not excluding possibilities yet. Still reading various researches before beginning higher level implementation. > Tor recently redesigned their rendezvous protocol for hidden services. I my context it would be entirely P2P without directory authorities, so there is a need for a different way of choosing introduction points. But this is above Ronion's responsibilities, so a bit out of scope of this thread. > If however you use only an unauthenticated stream cipher, or even a > regular block cipher, then this attack is catastrophic no matter what > other protections you employ. > > A circuit based design like Tor can defeat the simple attack using > authenticated encryption, but you can combine this attack with timing > attacks to defeat that, so they might prefer wide block ciphers too, not > sure. If you haven't actually take a look at Ronion yet - it assumes authenticated encryption between initiator and receiver and on top of that multi-layer non-authenticated encryption between hops. So in current design if you corrupt a couple of bytes somewhere in the middle of the process, nodes in routing path (think circuit) will just forward corrupted packet until it reaches responder (last node in routing path, not necessary receiver) and will be discarded. This will corrupt the state of the routing path after recipient if recipient is not responder node, but assuming that most if not all of the traffic is targeted at responder, state will remain consistent and I'm not really sure what is so catastrophic here. Also you can send garbage most of the time on the higher level, then Ronion's packets will only be only a small fraction of the total bandwidth, also you can tweak sending delays or apply other tricks, Ronion doesn't specify or care about that at all. Sincerely, Nazar Mokrynskyi github.com/nazar-pc _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
