[messaging] [Fwd: Re: Ronion anonymous routing protocol framework]
burdges at gnunet.org
Fri Oct 13 20:55:54 PDT 2017
On Fri, 2017-10-13 at 17:42 +0300, Nazar Mokrynskyi wrote:
> 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.
Afaik, there is nothing "useful" to do with protocols that are "like tor
but not tor" because tor appears general enough to do anything you
really want with circuit-based anonymity protocols.
Research is an exception of course, but most alternatives like I2P or
HORNET sound like a step backwards.
> > Tor recently redesigned their rendezvous protocol for hidden services.
> I my context it would be entirely P2P without directory authorities,
Right now, there is no known way to do this safely. I2P does it, but
afaik not safely. I donno if it's worse than using circuits in the
first place though.
GNUNet's RPS system is an improvement on some good ideas from the P2P
literature, but it's only a start, not designed for anonymity systems,
and any real solution requires much more work before it might
> 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.
Initiating a connection is usually considered to be part of the basic
protocol, otherwise you cannot really do anything.
> and on top of that multi-layer non-authenticated encryption between hops.
It needs to be a AEZ or another wide block cipher.
> 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.
If you do not use AEZ, then one can produce cryptographic proof of a
hidden service's identity: Just Run a hidden service guard that xors a
pattern into the data. And run a receiver that recognizes that
Tor might exhibit this problem too, not sure about their malleability.
I do know Tor wants to migrate to a wide-block cipher, but they might be
waiting on DJB, et al. to release HHFHFH instead of using AEZ.
> Also you can send garbage most of the time on the higher level,
This might be useless if you are using circuits.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Messaging