[messaging] [Fwd: Re: Ronion anonymous routing protocol framework]

[James McGlasan]

On Tue, Oct 17, 2017 at 10:31:55AM +0200, Jeff Burdges wrote:
> On Tue, 2017-10-17 at 06:06 +0000, James McGlasan wrote:
> > - 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. 

I mentioned this more for the point of performance, but this does reduce
the timing information that bidirectional relays learn. From the paper
[1].

Section 5.2. Passive De-anonymization

 Forward/backward flow correlation. The forward and backward headers are
 derived from distinct cryptographic keys and therefore cannot be
 linked. Only the destination is able to correlate forward and backward
 traffic, and could exploit this to discover the round-trip time between
 the source and itself, which is common to all low-latency anonymity
 systems. Sources willing to thwart such RTT-based attacks from
 malicious destinations could introduce a response delay for additional
 protection.

> > - 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? 

HORNET works fine without replay protection on the relays, the endpoints
can still detect all replays and if this is consistent for any specific
relay, then that relay may loose reputation and no one would use it. A
reputation system is not covered by HORNET, but external auditing and
localized heuristics will always be important for any such network.

> > - 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.

Yes, assuming I've read the following correctly.

Section 4.4.3.

 Processing for the backward path. Sending and processing a HORNET
 packet along the backward path is the same as that for the forward
 path, with the exception of processing involving the data payload.
 Because D does not possess the symmetric keys that each node on the
 backward path shares with S, D cannot onion-encrypt its payload.
 Therefore, instead of `REMOVE_LAYER`, D and the intermediate nodes use
 `ADD_LAYER` to process the data payload, and the source node recovers
 the data with `REMOVE_LAYER`.

> > 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
> protocol :
> https://gnunet.org/sites/default/files/Brahms-Comnet-Mar09.pdf
> 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.  

I've taken a quick skim over the paper and if I understand correctly, it
enables an arbitrary party to make a random selection of nodes, not
allow those nodes to randomly select themselves. That may be better
suitable for selecting relays, but not to populate the DHT bootstrap
PIR. Instead, we allow the DHT nodes to elect themselves, to register
into the PIR and audit the PIR service.

Auditing the PIR will work in two ways (1) any elected nodes verify
their own presence in the set by looking up their entry and (2)
performing random lookups to connect to random DHT nodes, then verify
that the real network is reachable through that node and we're not
enclosed under an eclipse attack.

Although only the elected DHT nodes may audit (1), anyone may audit (2).

The DHT will store the rendezvous point of the DHT node and the path
between these. This also serves the additional purpose of advertising
HORNET relays which the client may use to form their anonymised
connections to their bootstrap DHT nodes to then learn about more HORNET
relays, some of which may have shorter lifetimes for key rotation / weak
forward secrecy.

> > > 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
> people.

Fair.

> > HORNET will discard any corruptions early. 
> 
> This does not sound compatible with receiver anonymity.

Sorry, I mixed details between Sphinx and HORNET.  Sphinx* will discard
any corrupted messages at the relay that detects the corruption. HORNET
does not notice, but the endpoints do. To avoid tagging on a sphinx
based mixnet, a dummy payload may be used in place of omission.

Section 5.4.

 Payload tagging or tampering. HORNET does not use per-hop MACs on the
 payload of data packets for efficiency and because the destination
 would not be able to create such MACs for the packets it sends (since
 the session keys of the nodes are known only to the source). The lack
 of integrity protection allows an adversary to tag payloads.
 Admittedly, the use of tagging, especially in conjunction with replay
 attacks, allows the adversary to improve the effectiveness of
 confirmation attacks. However, end-to-end MACs protect the integrity of
 the data, making such attacks (at a large scale) detectable by the end
 hosts.


James.

 [1]: https://arxiv.org/abs/1507.05724