Dissentr: A High-Latency Overlay Mix Network

[Lee Azzarello]

Sounds like we need new terms for a high latency network that is a low
latency network or a low latency network that is a high latency network?

Perhaps store-and-forward versus stateful?

-lee

On Tuesday, September 24, 2013, David Vorick wrote:

> Tor is a low latency network in the sense that packets are forwarded as
> soon as they are received. Outwardly, it may not appear as a low latency
> network because ping times can exceed 30 seconds, however from a security
> point of view Tor is a low latency network.
>
> A high latency network is one that holds onto traffic until it has a huge
> batch to send out. With enough traffic, you could theoretically implement a
> high latency network that is faster than Tor, but a high latency network
> could also theoretical take days to respond to a request.
>
> With Tor, if you are observing every node in the network you can guess at
> people's identities by correlating traffic. If one node sends exactly X
> bytes to a node that sends the same number of bytes to the next node, you
> can assume that the two nodes are connected in a circuit.
>
> In a high latency network, you would wait to send data to the next node
> until you have many different requests to send to the next node. This makes
> traffic correlation a lot harder because you can't distinguish a particular
> request of X bytes from the other requests that are being sent over the
> network.
>
>
> On Tue, Sep 24, 2013 at 9:05 PM, Lee Azzarello <lee at guardianproject.info>wrote:
>
> Woah woah woah. When did the message go out about changing Tor to a "low
> latency" network? High latency is the number one criticism of Tor from
> users.
>
> In addition UDP traffic won't even pass through Tor. This results
> in low-latency real time applications like VoIP impossible over that network
> .
>
> Perhaps the author is not aware of these properties of Internet protocols?
>
> -lee
>
> On Tuesday, September 24, 2013, Eugen Leitl wrote:
>
>
> https://github.com/ShaneWilton/dissentr
>
> Note: This project was created as part of a 36-hour hackathon - and
> primarily as a proof of concept. While the ideas may be sound, and the
> prototype may work as designed, the protocols involved in this specific
> project have not been peer-reviewed, and so I cannot recommend that the
> network be used for anything requiring serious privacy.
>
> Dissentr
> A High-Latency Overlay Mix Network
>
> Essentially, Dissentr is a security-minded network, inspired by Tor, with
> a few important characteristics which serve to differentiate it.
>
> High-Latency
>
> Tor is a low-latency network. This makes it ideal for real time activities
> like web browsing, but as a result, opens it up to attacks involving
> large-scale traffic analysis methods known as end-to-end correlation. In
> these attacks, an adversary with the ability to analyze massive amounts of
> traffic in a short period of time is able to match up traffic entering the
> network with the corresponding traffic which will inevitably soon exit it.
>
> Dissentr manages to protect against these sorts of attacks by being
> engineered as a high-latency network. Assuming any given node has not been
> compromised, that node will intentionally hold off on forwarding its
> traffic to the next node in the network until it is able to forward a large
> amount of data in bulk, rendering the aforementioned end-to-end correlation
> far less feasible. For an excellent discussion on this attack, and possible
> countermeasures, see Practical Traffic Analysis: Extending and Resisting
> Statistical Disclosure.
>
> Cascades
>
> Much like any mix network, Dissentr models its network as a graph of
> nodes, each responsible for handling the relay of traffic as it moves along
> some path through the network. Where Dissentr differs from a network such
> as Tor is in how this path is constructed. In Dissentr, the network is
> constructed out of cascades (A term I first heard described by Ian
> Goldberg, but I've been unable to pin down an original source for):
> essentially directed, acyclic sub-graphs, in which a node defines a set of
> "trusted" nodes, through which they are willing to relay traffic through.
> Dissentr simplifies this model by only allowing for nodes of out-degree 1,
> at this time. This construction brings about a number of useful results:
>
> In the event that a node is known to be compromised, individual nodes are
> allowed the ability to either remove themselves from a cascade, or bypass
> untrusted nodes entirely, without the necessity of a trusted third-party.
> The network is protected from "supernode invasions," in which an attacker
> floods the network with compromised nodes, in the hopes of either
> endangering the network's health, or placing the security of users passing
> through their nodes at risk of traffic interception, and subsequent
> analysis. This can be guaranteed because cascades are constructed by virtue
> of a measure of trust between node-operators, and so long as there exists
> some non-zero subset of trusted operators, they retain the ability to form
> a cascade of their own, effectively shutting out the efforts of such an
> attacker.
> Use-Cases
>
> As mentioned previously, the high-latency nature of the network causes a
> shift in the sorts of activities best facilitated by its use, however,
> there do exist some unique opportunities which I have neither seen
> implemented in the context of a mix network, nor discussed in the
> literature.
>
> A personal favourite idea revolves around creating a platform for
> political blogging, which, assuming a noisy enough network, would offer
> political dissidents the ability to freely write about issues of corruption
> or government abuse, without many of the risks associated with using a
> lower-latency network like Tor. If it takes a week for a blog post to
> appear in circulation after the author posts it to the network, it becomes
> magnitudes more difficult for any assailant to
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6641 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20130924/20c585c9/attachment-0001.txt>