Dissentr: A High-Latency Overlay Mix Network

Tue Sep 24 14:19:51 PDT 2013

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 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 at 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
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 10001 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20130924/97c74392/attachment-0001.txt>