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

[James McGlasan]

Disclaimer: I have not read much of the Ronion "spec", I disagree with
design and advocate strengthening already well designed protocols like
HORNET. I am working on a HORNET implementation and some details below
may be bias towards my plans and may not apply for Ronion.

On Sat, Oct 14, 2017 at 05:55:54AM +0200, Jeff Burdges wrote:
> Research is an exception of course, but most alternatives like I2P or
> HORNET sound like a step backwards.

Could you elaborate on why these sound like steps backwards? Especially
HORNET as it is AFAIK the state of the art in onion routing and I plan
to implement it.

Re-cap for anyone not familiar with Sphinx or HORNET:

- Paths are undirectional and do not rely on slow (latency)
  bidirectional-telescoping to establish connections.

- Relays do not maintain any per-connection or flow state. (cheaper on
  memory and file descriptors)

- Relays do not know their position on the path, nor do they know
  how many hops have been used. They know only the static max hops and
  if they are encrypting (towards an endpoint) or decrypting (towards a
  rendezvous point).

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

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.

The PIR service can be populated with a randomly elected subset of the
larger DHT using VRFs to enable the DHT nodes to learn and prove that
they won the lottery, without revealing to any adversaries before they
redeem the proofs. For more information on the VRF-based sortition see
https://ia.cr/2017/454

Sybil attacks apply regardless to this topology, the only defences are
to make such attacks more expensive (proof of work?) or less likely to
be positioned (random and hard to control) such that the adversary gains
any advantage. The DHT would be proportial to the number of relays +
users and each honest relay or user may host multiple DHT nodes to
further increase the costs of mounting a sybil attack.

> > and on top of that multi-layer non-authenticated encryption between
> > hops.
> 
> 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, you may
instead use an MRAE[AAD] where the header is the AAD and the tag may be
detached and sent in place of the MAC.

Note the added benefit of using an MRAE, as the name (nonce-Misuse
Resistant Authenticated Encryption) implies, if a `(key, nonce)` is
ever repeated, there is no catastrophic result such as revealing
plaintexts (like KRACK) or keys. Another example for this argument is if
someone runs your nonce-sensitive software in a virtual machine, creates
a snapshot and later resumes old state, the `(K, N)` tuple may repeat.
Or if any backup-and-recovery process doesn't take this into account or
if an internal counter overflows or fails to increment.

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

You almost described a tagging attack. You want to discard early or let
the client detect the event and decide if they want to distrust any
intermediate relays.

HORNET will discard any corruptions early. Although without expensive
bloom filters, it won't filter out replays. Replays and traffic shaping
may be used as a side channel, but they can be detected by the
endpoints.

If your threat model is sensitive to tagging or traffic shaping, you
should be using a mixnet, not an onion router.


James.