Re: [tor-talk] TOR Research Project

["Gerardus Hendricks" <konfkukor@xxxxxxxxxx>]

> Or let me know where I should begin reading?

You need to start reading here: http://freehaven.net/anonbib/
All collected and tidied up for you.

Skim through the abstracts of at least the 'boxed' papers.

> I was looking at the volunteer page under research and
> found the end-to-end traffic confirmation attack topic
> interesting.

"End-to-end traffic confirmation" as it is presented at the developer
page, is only concerned with comparing traffic signatures between two
targets. It doesn't concern itself with actually finding Alice and Bob in
the first place. You could compare the two streams on (the size of) the
content, but also on timing information.

Timing information of a traffic stream is very revealing, and is for a
large part outside the control of Tor: a human can't tweet while sleeping
and your computer needs to be on to be able to connect to the internet.
More importantly, the way the modern web works requires constant
interaction between client and server. That means that Tor traffic must be
relatively low-latency (order of seconds) to be even functional.

There exist high-latency mix networks, designed primarily for sending
email because the medium of 'letters' is tolerant of latencies of hours.
See the Mixminion paper of 2003 for that, but be sure to skip entire
sections.

Mixminion's goals isn't really to try to defend against the "end-to-end
traffic confirmation" attack as described on the research pages. It tries
to protect itself against a classic global passive adversary (first
paragraph of section 8.1). For brevity, we could call such an attacker the
NSA.

Global passive attackers simply listen to all communications. It is often
assumed that the specific protocol is encrypted and that the attacker
cannot decrypt the streams. It can however see who sent how much data when
to whom. "Who" and "whom" mostly refer to network addresses, but
ultimately concern some bureaucratic entity (an organization or a human)
or something in physical space (a machine or a body).

It is not feasible to listen to all communications, let alone correlate
the traffic signatures. The question then becomes how much and which
traffic signatures an attacker would need to see to be able to find out...
what? There are several adversary models. A recent paper describes how
listening to a single AS could deanonymize users within a certain
timeframe having certain communication habits with a certain chance. If I
remember correctly, the paper simply assumes the "end-to-end traffic
confirmation attack" on timing information you are talking about:

http://freehaven.net/anonbib/cache/ccs2013-usersrouted.pdf

Regards,
Gerard

---

(I made a separate post for this)

As an aside, I'm really interesed in how we could modify or build an
adapter to the web so it is more tolerant of high-latency interaction.
Seeing recent events it seems prudent to start thinking of ways in which
common applications could (for a small part) function in a high-latency
environment. We need to have a SlowTor.

It could for example work really well for many read-only uses of
applications, like reading web pages or other structured data (tweets,
video, maps, comments). A high-latency proxy to the open internet would
require nodes to cache content. The main problem is denial of service: how
to prevent nodes from forging the data itself? We assume that for the most
part, publishers won't be bothered to cryptographically vouch for the
authenticity of the data (like Freenet requires). A best-effort service
combined with BadNode flags would already be a lot.

On the writing side of things, I find it really hard to imagine how
high-latency connections would work with a modern web. Note "web", and not
"internet". I would be thinking of browser plugins written in Javascript,
that communicate with a backend that connects to the mix network. What
functionality must such a backend provide to the application?

An aside of an aside: if a node would provide a complete (non PFS) TLS
conversation between him and a webserver, could a 'verifyer' that is
agrees on the certificate belonging to that Common Name, verify that the
data contained in the conversation was indeed sent by the server in
possession of the private key belonging to that certificate?

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk