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 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 trace the authorship of that blog post - especially if that author never visited the website which hosts their content in the first place!

It also becomes a fairly trivial exercise to adapt the network to act as a mixing service for digital currency such as Bitcoin. Furthermore, by breaking the network into a number of smaller, disjoint networks for that purpose, one is be able to counter many of the current attacks which target existing mixing services.

Cryptosystem

I again emphasize that the cryptosystem in place is the result of a rather rushed 48-hour hackathon - in a production system, I would recommend implementing a peer-reviewed cryptosystem, such as the very lightweight Sphinx, or, pending their coming proof of security, the recently proposed Ibis. That being said, Dissentr works as follows:

Every node in the network maintains an RSA-keypair, with the public key being exposed to every node in a given cascade. When a client wishes to send a message M through the network, they choose some cascade C. For each node in the cascade, beginning with the exit node, and continuing through to the entrance node, the client generates an AES CFB128 key, which it uses to encrypt M. The key is then encrypted using that node's public RSA key. M, now encrypted with AES CFB128 for every node in the cascade, is then passed to the entrance node along with the encrypted AES keys. The entrance node then uses its private RSA key to decrypt the AES key, so that it can subsequently decrypt M, yielding yet another cipher text. This process is repeated for every node in the cascade, until the final node decrypts M to a plaintext, which it then handles accordingly. Building and Running it

If, after all of my warnings, you still want to see it in action, it's dead-easy to get setup. All you'll need is Erlang installed (Tested on R16B02), along with Elixir. From there, you'll want to invoke the following from within Dissentr's directory, on every machine you want to host a node:

iex --sname {Any name, different per machine} --cookie {Any string, common between all machines} -S mix This will stick you into a REPL, loaded with Dissentr's namespaces and dependencies. Sorry, there's no interface yet. From there, if you're using more than one machine, you'll want to link them all together, by running the following on every machine you want to host a node on. Since Erlang node connections are transitive, you won't have to do this for every pair of nodes.:

:net_adm.ping(binary_to_atom(hostname)) The hostname in question can be found in the iex prompt. Most likely it will be something@domain.

Now, just spawn a few nodes to create a network. I've got some temporary methods in place for making this easy, using some hardcoded keys stored in example_data/ for testing. Ideally, each node will be hosted on a different machine, but for testing purposes it doesn't matter. Within your prompt, execute the following:

Dissentr.Cascade.add_node(:node1, nil, 1) Dissentr.Cascade.add_node(:node2, :node1, 2) Dissentr.Cascade.add_node(:node3, :node2, 3) Dissentr.Cascade.add_node(:node4, :node3, 4) Dissentr.Cascade.add_node(:node5, :node4, 5) Finally, to send an encrypted message, run the following, substituting the node and message as desired:

Dissentr.Cascade.mix(:node3, "Something, something, NSA") If all went well, you should see a debug statement print out the plaintext message, on the machine which is hosting :node1

On Tue, Sep 24, 2013 at 05:53:00PM -0400, Lee Azzarello wrote:

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?

There's already DTN, so why not adopt that term.