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

[Jeff Burdges]

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

I doubt this helps against website fingerprinting, but maybe it helps
against less predictable data flows, like uploading your own file to a
server where you can pause randomly.

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

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.

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

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'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, 

As I said, it's maybe good enough for routers selecting other routers,
but not for client nodes building paths.

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

Why?  It avoids some sybil attacks? 

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

I don't understand this.

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

Right, there is no "body" in HORNET's Sphinx packets.

Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171017/b33ec4db/attachment.sig>