[messaging] [Fwd: Re: Ronion anonymous routing protocol framework]
burdges at gnunet.org
Tue Oct 17 01:31:55 PDT 2017
On Tue, 2017-10-17 at 06:06 +0000, James McGlasan wrote:
> Could you elaborate on why these sound like steps backwards?
Actually I'm not familiar enough with HORNET to criticize it, but..
> - Paths are undirectional and do not rely on slow (latency)
> bidirectional-telescoping to establish connections.
I've never read any analysis showing that unidirectional paths improve
protections, but maybe.
> - Relays do not maintain any per-connection or flow state. (cheaper on
> memory and file descriptors)
Afaik HORNET does not work unless you add replay protection, making it
ultimately stateful, no?
> - Relays .. know only .. if they are encrypting (towards an endpoint)
> or decrypting (towards a rendezvous point).
Really? Are you sure HORNET nodes know if they are encrypting or
decrypting? That sounds unlikely to me.
> A PIR service may be used to bootstrap a DHT network whose nodes are
> hidden by the onion routing protocol itself. I plan to use S/Kademlia
> for my implementation, although this may be replaced with a byzantine
> fault tolerant DHT later.
I'm not familiar enough with recent things here, but one protocol I know
of basically glues a cheap PIR inspired layer onto a Byzantine gossip
It sounds okay for informing routers about other routers, but it'll
leave clients vulnerable to epistemic attacks.
I've never heard anyone propose hiding queries in the onion routing
protocol. It sounds like the right direction to me, but network people
tend to like their layers.
> > It needs to be a AEZ or another wide block cipher.
> Why aren't you authenticating? We want to reduce malleability and
> tagging attacks! Sphinx and HORNET use unauthenticated encryption for
> the payload and a MAC to authenticate the payload and header,
We were talking about the payload because he was talking about onion
services. I avoided bringing up the Sphinx header because it'd confuse
> HORNET will discard any corruptions early.
This does not sound compatible with receiver anonymity.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Messaging