> 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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
