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

[James McGlasan]

On Tue, Oct 17, 2017 at 03:07:57PM +0200, Jeff Burdges wrote:
> I doubt reputation provides much protection for targeted users, like
> onion services, because (a) the attacker controls numerous recipients
> in this scenario, so (b) the attacker can make use traffic analysis to
> improve their guesses, minimizing reputation damage, and (c) attackers
> can poison the reputation system with fake reports about good guards.  
> 
> There might be "verifiable" schemes through which onion services could
> be notified by their own clients that their guard miss-behaved,
> thereby prompting the onion service to close down and physically move
> servers to another ISP.  Ain't so easy to tell the difference between
> a adversarial guard and second hops trying to force onion services to
> spend money changing servers though.  I doubt this works for
> protecting targeted clients from bad exit nodes though.
> 
> Anyways, I think the real answer here is simply that HORNET was
> designed entirely for speed in Tor-like use cases, and they are
> willing to make additional anonymity compromises beyond what Tor does
> to get there.  I donno if anybody actually understands enough about
> the relative costs of attacks on onion routers to say what is correct.

I agree this is a tough problem - and although I mentioned the *idea* of
reputation, I don't have any solid plans for this.

> Your quote lacked context, but sections 4.4.{2,4} make it clear that
> they want an IV for the packet body for some reason.  
> 
> I do not understand why they cannot simply use a wide-block cipher,
> perhaps with an internal "IV" as additional data.  It might be
> performance since Lioness is slow, but AEZ is not slow, and HHFHFH
> should be fast whenever DJB et al publish it.

I'd like to simplify the constraints and use an MRAE but a fast
wide-block cipher may suffice as specified. I know this is easy for
Sphinx, but I'm not sure about HORNET. Do you have any references for
the seemingly only teased HHHFHF?

> > PIR. Instead, we allow the DHT nodes to elect themselves, to
> > register into the PIR and audit the PIR service.
> 
> Why?  It avoids some sybil attacks? 

Partially. We audit the PIR services because they are trusted
and centralized-ish. We must be able to hold them accountable if they
fail to advertise honest nodes (as proven by the registered nodes
looking up their entries), or if they inject many eclipse nodes that
simulate an isolated network or hide certain keys from being
successfully queried. The former case can only be a misbehaving PIR,
while the later may be a large sybil 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

The *PIR* will store .. - although the DHT does maintain the same
information for routing (and a lot more of them).

> > between these. ..
> 
> I don't understand this.

PIR.store(DHT node public key, [onion paths to DHT node])

A DHT node is just an onion service, to access it you must know the
rendezvous point and an encrypted path from that RP, to the service. The
PIR stores these records for the DHT nodes that are elected.

The PIR advertises DHT nodes and incidentally the information required
to reach a DHT node implicitly advertises HORNET relays that the client
may use to construct an anonymised path to their chosen bootstrap DHT
nodes; which introduce the new client to more DHT nodes (and
paths/relays).

The DHT only stores onion service descriptors, in the same style as
tor's v3-onion services with blinded or "semi-private" keys such that no
DHT nodes cannot scrape their data to connect to arbitrary services. To
connect to a service, someone must give you the credential to access it.
(like the new .onion addresses).


James.