Dynamic Multipath Onion Routing in Anonymous Peer-To-Peer Overlay Networks

Olaf Landsiedel, Alexis Pimenidis, Klaus Wehrle Heiko Niedermayer, Georg Carle Department of Computer Science Department of Computer Science RWTH Aachen University, Germany University of Tuebingen, Germany fi[email protected] fi[email protected]

Abstract— Although recent years provided many protocols for Instead of using a static route between two nodes, MORE anonymous routing in overlay networks, they commonly rely on routes each packet along a different path to its destination – the same communication paradigm: Onion Routing. In Onion making timing and pattern attacks, as the one described above, Routing a static tunnel through an overlay network is build via layered . All traffic exchanged by its end points is useless. Furthermore, the stateless forwarding is inspired by relayed through this tunnel. IP-routing. Thus, a relay does not maintain state and flow In contrast, this paper introduces dynamic multipath Onion information for connections as in today’s Onion Routers. This Routing to extend the static Onion Routing paradigm. This reduces the complexity of the design and the architecture, approach allows each packet exchanged between two end points allowing for the ease of implementation of relay nodes. to travel along a different path. To provide anonymity the first half of this path is selected by the sender and the second half Additionally, dynamic multipath Onion Routing results in an by the receiver of the packet. The results are manifold: First, improved load balancing compared to traditional static Onion dynamic multipath Onion Routing increases the resilience against Routing. As result the impact of misbehaving or overloaded threats, especially pattern and timing based analysis attacks. nodes on the throughput is reduced. Second, the dynamic paths reduce the impact of misbehaving Additionally, peer-to-peer networks have a number of prop- and overloaded relays. Finally, inspired by Internet routing, the forwarding nodes do not need to maintain any state about erties desired in Onion Routers: The large number of available ongoing flows and so reduce the complexity of the router. nodes, their geographic distribution and local jurisdiction and In this paper, we describe the design of our dynamic Multipath political backgrounds make such a widely distributed network Onion RoutEr (MORE) for peer-to-peer overlay networks, and an ideal candidate for anonymous communication and as result evaluate its performance. Furthermore, we integrate address our work bases on a peer-to-peer overlay. virtualization to abstract from Internet addresses and provide transparent support for IP applications. Thus, no application- The remainder of this paper is structured as follows. First, level gateways, proxies or modifications of applications are section II addresses related work and discusses the differences required to sanitize protocols from network level information. to our approach. Section III presents dynamic multipath Onion Acting as an IP-datagram service, our scheme provides a Routing and transparent support of IP applications. Section IV substrate for anonymous communication to a wide range of introduces anonymous services and section V evaluates the applications using TCP and UDP. performance of the proposed approach. Section VI discusses I.INTRODUCTION future work and concludes the paper. Anonymous routing and forwarding enables private com- munication in today’s Internet. Its applications include private II.RELATED WORK webbrowsing, online voting and anonymous , chats and In this section, we address the differences of today’s content distribution. Syverson et al. proposed Onion Routing near real-time anonymous communication schemes to our [1] as a substrate to enable anonymous communication. Using approach. Their design principle dates back to the Chaumian Onion Routing, a host can connect to a server through a set of Mix [5], in which e-mail traffic is forwarded through a set relays and thereby hide its identity. Layered encryption ensures of cascading mixes to hide the sender’s identity. The traffic that each hop in the relay network can only decrypt the address enters one of the mixes and leaves the at some of its successor in the relay chain. random point. To reduce the impact of malicious mixes, the To communicate, two nodes set up a route through the relay route through the mixes is set up via layered encryption (Onion network. As this route remains the same until the communica- Routing [1]). Thus, each mix only can decrypt the information tion between the two nodes has ended, the connection-based about its successor in the cascade. design of today’s Onion Routers enables practical attacks Based on the Onion Routing principle, various systems against the user’s anonymity such as [2]–[4]. For example, to have been proposed enabling near real-time communication attack a connection, the adversary applies a traffic pattern to for services like web browsing: [6], Freedom [7] and Web one of the relays of the connection. This pattern then interferes Mixes [8]. These systems either use a centralized proxy for with the communication between the server and the node and relay or a set of known relays. With the success of peer-to- can be measured at both of them [2]. peer systems the peer-to-peer paradigm got adapted by various anonymous communication schemes such as as MorphMix [9], Hop 1 Hop 2 Hop 3 Hop 4 Receiver Data… Tarzan [10], AP3 [11], Cashmere [12], and information slicing Enc. with public of rec. [13] . The large number of available nodes, their geographic Encrypted with public key of hop 4 distribution and local jurisdiction and political backgrounds Encrypted with public key of hop 3 make such a widely distributed peer-to-peer network an ideal candidate for anonymous communication. However, peer-to- Encrypted with public key of hop 2 peer networks suffer from the dynamics of nodes leaving Encrypted with public key of hop 1 and joining constantly and the heterogeneous bandwidth and Hops selected by the sender Hops selected by the receiver computing capacities of their nodes. Nonetheless, all systems mentioned above rely on static routes and are thereby suscep- Fig. 1. Path information: the layered public key encryption ensures that each tible to pattern- and timing-based attacks [2]–[4]. hop can only determine its successor. To our best knowledge, our work is the first to propose dynamic multipath Onion Routing, i.e. to route each packet along a different path, for low latency anonymous networks. adding its own public key to the header, it ensures that the Focusing on traffic analysis of Mobile IP systems and not relay itself can retrieve the symmetric key and determine its anonymity and Onion Routing, Fasbender et al. [14,15] show successor on the path (see figure 1). Applying this scheme to that changing Mobile IP agents on a regular basis makes traffic each hop, MORE ensures that each relay knows only about analysis unfeasible. The closest work to MORE is a theo- its successor. Additionally, packets to constant length retical paper by Serjantov and Murdoch [16] about splitting prevents relays from identifying the length of the path and large messages in remailer systems [17, 18]. It analyzes the their position in it. usage of independent routes for each packet of a message To reduce the computational and the bandwidth overhead to prevent an eavesdropper at the first mix from determining we use elliptic curve cryptography (ECC). Compared to RSA, the message size and therefore being able to correlate this ECC keys are significantly shorter. We use a key length of with an eavesdropper located near other mix nodes. As nodes 192 bit, which has a similar to 2048 bit RSA are repeatedly used as first relay in a path, the packet flow keys. Additionally, encryption, decryption, key generation, and is exponentially distributed to prevent the first relay from elliptic curve based Diffie-Hellmann key exchange (ECDH) estimating the message size. This theoretical analysis primarily are significantly faster than in RSA-based schemes [19]. refers to remailer systems. However, in private communication Additionally, the sender adds a return route – leading back its authors confirmed that most arguments in terms of security to itself – to the packet. Using this return route, the receiver and threat analysis also apply to Onion Routing. can send an answer back to the sender. When forwarding a packet, a relay stores the previous and next relays and the III.INTRODUCINGTHE MORE APPROACH corresponding key for some minutes to prevent the reuse of routes. This is important as the repeated use of a route would This section introduces dynamic multipath Onion Routing. enable pattern and timing based attacks and so threaten the In particular, we discuss the architecture of MORE. anonymity of the path destination. Today’s Onion Routers operate flow oriented. Thus, when a flow between two end points is set up, each relay stores A. Path Concatenation session information, e.g. symmetric keys, state information, successor, and predecessor. In contrast, MORE allows each So far, we discussed how a sender can communicate anony- packet to travel along a different path. To provide anonymity mously with a known receiver. However, we did not discuss the first half of this path is selected by the sender and the how the receiver itself can stay anonymous and so offer for second half by the receiver of the packet. As MORE operates example a hidden service. connectionless, a session setup as in today’s Onion Routers We propose a path concatenation scheme to enable receiver cannot be done1 and is unnecessary2. Therefore, in MORE, anonymity. An anonymous service (hidden service) publishes each packet needs to maintain the information about the relays routes to itself in some out-of-band media (see section III-B). in path and corresponding cryptographic keys. The sender retrieves this information and adds its own hops MORE uses Diffie-Hellman key exchange based on elliptic to the route by adding further layers of encryption to the path curve cryptography to generate symmetric keys for decrypting section. For example, assume that Bob offers an anonymous the information about the successor on each relay. Assume service, that Alice wants to communicate to this service, and that the sender has generated a public / private key pair that she retrieved a route to the anonymous service. First, Alice and that it knows the public key of the relay. From its own selects a number of random nodes to relay her traffic in order private key and the relay’s public key, it can retrieve a shared to stay anonymous herself (see figure 2). Next, Alice concate- secret, i.e. a symmetric key. With this key, it encrypts the nates the nodes she selected and the communication path she information about the next hop(s) and the destination. By retrieved. Thus, she selected the head and Bob the tail of the path (see figure 1) and both stay anonymous. Interestingly, 1This is good for security reasons. Alice needs to retrieve the anonymous path to Bob’s service 2This is good to achieve a small memory footprint. only to set up communication. Once Alice reached the hidden Alice (Sender) Bob (Receiver) multipath Onion Router feasible. However, ECC is still slower 2 by an order of magnitude than symmetric key operations [19]. 3 Thus, MORE allows clients to reuse keys. Combined with 1 caching done by the relays the number of ECC operations can 4 Anonymous path Hop selection be reduced drastically. Packet forwarding consists of two operations. First, a relay Fig. 2. Sender and receiver independently select a number of hops of the computes the symmetric key via Diffie-Hellmann key ex- anonymous communication path. change and then decrypts the packet with this symmetric key. Of these two operations, the Diffie-Hellmann key exchange is the more computationally expensive one, as it bases on service, anonymous path sections are piggybacked on the data asymmetric cryptography. Thus, MORE tries to reduce the traffic. overhead of this operation. Furthermore, the MORE design has to ensure that nobody can impersonate an anonymous service and offer – potentially When a MORE node uses a relay again, at any point malicious – own services instead. We use public / private in the relay path, it can reuse the same key set with a key-based signatures to protect against impersonation. Thus, certain probability. Thus, the sender and the relay cache the Bob computes a key pair and the public key becomes his asymmetric and symmetric keys for a while. When a key is anonymous identity (e.g. ). When Bob publishes reused, the sender and the relay do not need to recompute the a path section, he signs it with his private key. Knowing the corresponding symmetric key. Our evaluation (see section V) anonymous identity, a MORE node can verify the issuer of shows that key caching can drastically increase the throughput path sections. of the MORE system. Note that this technique allows relays, sender and receiver each two distinctive choices: sender and B. Service Directory receiver have the choice to decide themselves between per- As discussed in the previous section, MORE needs a lookup formance and confidentiality, while relays have the possibility service to provide paths to initiate communication to anony- to choose a tradeoff between processing power or memory. mous services. In MORE, the service directory provides this As the key reusage rate can be chosen by each MORE client information. To hide its identity, a MORE node communicates individually, we expect this feature to have a positive impact with the service directory anonymously. In more detail, it on the deployment. provides the following services: • Relay discovery: each MORE node can retrieve other D. Legacy Support MORE nodes from the directory and use these to relay traffic. Furthermore, it registers itself as relay. Retrieving For a fast adoption of MORE by a wide user range, it is MORE nodes can be done anonymously or directly to necessary that users can reuse their unmodified networking ap- enable bootstrapping. plications in the MORE environment. Commonly, networking • Virtual IP addresses: to address anonymous services, applications use TCP and UDP protocols, which themselves each MORE node can retrieve a virtual IP address use the IP protocol. To provide support for such so called (e.g. 10.2.3.79) from the service directory. This IP legacy applications MORE resides on the network level and is address is unique in the MORE system and other nodes transparent to applications, i.e. MORE provides an IP overlay can use it to address and to connect to a service. to the application. • Name Service: next to virtual IP-addresses, we allow It is necessary that outgoing packets of a MORE node do MORE nodes to register a domain name. not contain any information about its real identity, e.g. its • Path sections: to connect to a service, the sender needs IP address. Commonly today’s anonymous communication to retrieve a path section pointing to the desired service. schemes use application-level gateways or proxies, but this Thus, a service can store such path sections in the service requires the gateway or proxy to know the protocol formats directory. of all applications used. Due to the large number of existing The service is designed to be deployed on be a scalable and application level protocols we do not consider this engineering redundant Distributed Hashtable (DHT) as all operations rely effort reasonable. Furthermore, some protocols are propri- on simple put and get operations. However, in our current etary and their formats are not published. MORE addresses protype implemention, we use a dedicated machine. When this problem by using an “anonymous communication stack” communicating with the service directory, a MORE node signs which is assigned a virtual IP address, e.g. 10.2.3.79 (see its messages to prove its anonymous identity. Fig. 3). The essence of this address virtualization technique is to abstract away any information about the identity of a node C. Key Caching while remaining compatible with the IP addressing scheme and MORE benefits from elliptic curve cryptography as its keys applications that depend on it. We use the service directory are shorter and cryptographic operations are significantly faster (see section III-B) to anonymously assign unique virtual IP than traditional RSA. These two factors make the design of a addresses to each node. USUser Space MORE is designed to prevent pattern analysis and packet Multipath Onion Router Anonymous Application counting attacks inside the network. This improves the (MORE) e.g. , chat, ssh anonymity in comparison to existing systems for interactive

TCP / UDP System near-real-time traffic in a crucial point. Important measures to achieve this anonymity in addition to the basic approach of dynamic multipath Onion Routing are: (1) unlimited and

IP Space random path length, (2) uneven distribution of flows among 3 NIC Driver Virtual NIC (10.x.y.z) first or last hop to address packet counting attacks such as [3] , (3) selection of location/IP-diverse paths and (4) avoidance of long-lived identities. Network Interface (NIC) IV. MORE AND INTERNET SERVICES Hardware “Traditional” Communication Stack Anonymous Communication Stack In this section, we discuss how services can be deployed in the MORE network. We distinguish two classes of services: Fig. 3. The virtual network interface enables transparent application support. (1) anonymous services and (2) exit points. As MORE is an IP overlay, a MORE node can provide the same services as a server in the Internet. Thus, it can run a E. Naming Service web server, ftp server, ssh, content distribution, or streaming For a seamless integration of existing applications, a name services. Introducing the virtual .anon domain makes it very service is required. Users need a way to address anonymous intuitive for the user to connect to an anonymous service. services and to distinguish them from Internet-based ones. Furthermore, a node can act as exit point. Exit points bridge Thus, we provide a name service, which is transparent to between the anonymous MORE network and the Internet itself. the existing Domain Name Service (DNS), in order to map Therefore, a MORE node can communicate anonymously to between DNS requests and anonymous services. Users can any Internet based service, for example a web-site, via an enter http://www.freespeech.anon into their web- exit point. An exit point can provide access at two different browsers and connect to an anonymous service. When a protocol layers: (1) it can operate at the transport level and .anon domain is queried, the system sends a DNS request in act as NAT device or (2) it can operate at application level, order to resolve this domain. Our scheme reroutes this request for example as an HTTP-proxy. As MORE operates on the to the MORE service directory and determines the virtual network level and is accessed by the applications via the virtual IP address and corresponding communication paths from the network interface, standard off-the-shelf http-proxies and NAT service directory. To distinguish between traditional domain software can be used. Additionally, we allow the operator of names and the anonymous ones, we introduce new domain an exit point to introduce their own exit policies by restricting names, like .anon, as used in the previous example. protocol types, destinations, and consumed bandwidth. Compared to many other existing anonymous communica- F. Security Considerations tion schemes [6,9]–[11], MORE provides a seamless integra- Due to space limitations, this paper focuses on the design of tion of anonymous services and exit points within the overall the dynamic multipath Onion Router. For an extensive security architecture. analysis we need to refer the reader to an extended version of this paper [20]. Nonetheless, we want to shortly introduce the A. Communication Example threat model and design extensions besides the basic multipath Connecting to a service in the MORE architecture consists Onion Routing paradigm. of two steps: (1) retrieving a path to the service and (2) Commonly, a global passive adversary is the assumed threat communicating to the service itself (see figure 4). In this when analyzing theoretical anonymity designs. However, like section, we discuss these two steps in more detail. Let Alice all practical anonymous communication schemes that are scal- connect to the service www.freespeech.anon and assume able and enable low-latency communication, MORE can not that Alice knows some MORE nodes that can relay traffic for protect against such a strong adversary. Furthermore, similar to her. its predecessors, MORE does not prevent (usually long-term) Alice enters www.freespeech.anon into her web intersection attacks by local adversaries. browser. As a result, the web browser sends a DNS query We assume a practical adversary which can: to resolve the domain name. In the network stack, the MORE • observe a limited part of the network application intercepts all queries for the .anon domain and • participate in the MORE network with a limited number thereby ensures that the query does not leave the host and of relays. leaks information about Alice’s intentions. Instead of com- • participate actively by offering a service, e.g. running a municating to a standard DNS server, the MORE application web server. 3This attack adds a number of malicious nodes to the network and • influence communications by generating, delaying, drop- eventually a user or hidden service will use these to relay traffic and thereby ping, and modifying traffic content and patterns. reveal its identity queries – via a number of relay hosts – anonymously the 32 byte header. Thus, MORE’s overhead is 32 bytes per relay, service directory. From the directory, it retrieves the virtual which we consider reasonable. Additionally, MORE uses a IP address of www.freespeech.anon and some paths to cell size of 1000 bytes to further reduce the header overhead. it. After retrieving this information, the MORE application sends a fake DNS reply back to Alice’s web-browser. Next, B. Performance the web-browser initiates a number of TCP connections to the We deployed MORE on our test network which consists web-site. As the destination address is a virtual IP address, of eight Linux hosts (5x Pentium IV 2.2 GHz, 3x Xeon 2.8 packets are routed via the anonymous communication stack GHz) running Fedora Core 4, interconnected by a 100 MBit/s into the virtual network interface. Thus, the MORE application network. relays them anonymously into the MORE network. Each host acts as relay and one of the hosts offers an anonymous service. Another one communicates to this service V. EVALUATING THE MOREARCHITECTURE via TCP. For the evaluation, sender and receiver use three In this section, we evaluate the proposed architecture. First, relays each, resulting in a total of eight hops. Our evaluation we introduce implementation details, and then through- has shown, that the overlay throughput, i.e. the net throughput put measurements. Finally, we discuss our ongoing work of that an application running on top of the MORE overlay deploying MORE in the “wild”. can use, can drastically be speed up by key caching as it MORE, in contrast to existing anonymous near real-time reduces the need for asymmetric cryptography. When making communication schemes, relays each packet via a different full use of key caching, the throughput reaches 2.5 MBit/s. path (dynamic multipath Onion Routing), which results in This throughput is similar to the throughput the Tor anonymity interesting implementation challenges: network reaches in a testbed. For example, for a four hop con- • Bandwidth and performance overhead: when each nection (compared to the eight hops in MORE) the meanwhile packet is routed along a different path, no relay tunnel can highly optimized Tor implementation achieves a throughput of be set up and no connection establishment is done. There- 3.6 MBit/s (Dual PIII, 1 Ghz). fore, no shared secrets can be bound to a tunnel. Instead, Our measurements identify two limiting factors for the MORE has to rely on asymmetric cryptography, which throughput in MORE: (1) overlay TCP retransmissions caused is computationally expensive. Furthermore, as each hop by high round trip variance and (2) CPU processing perfor- through the mix cascade requires a key to be embedded mance, where the cryptographic operations mainly cause the in a packet’s header, MORE needs to with additional processing load. When making full use of key caching, the bandwidth overhead. overhead of asymmetric cryptography is removed from the • Round-trip time variance: routing each packet along a system. As result it this case MORE only uses symmetric different path results in a highly dynamic communication cryptography – just as Tor – and therefore reaching a similar scheme. Some packets will be on routes with low round performance and security level. trip times due to proximity or low load while other pack- Nonetheless, it can be said that TCP was not designed to ets will have high round trip times. This results in packets cope efficiently with dynamic overlays as MORE and its high being delivered out of order at the final receiver. In case of variance of round trip times. However, we evaluated that (1) an overlay TCP connection, TCP misinterprets this out- packet play-out smoothing to limit out-of-order delivery and of-order delivery as packet loss, its fast retransmission (2) per-hop acknowledgments reduce packet loss and thereby mechanism leads to additional packets and a decreased increase TCP performance. Currently, we are implementing overall throughput. However, in the recent years various these features in combination with recently proposed conges- TCP extensions and algorithms [21]–[24] were proposed tion control algorithms [21]–[24] for TCP overlay connections to enable efficient TCP flows and congestion control in in MORE to achieve further performance improvements. The multipath overlays. Our ongoing work focuses on the goal is the design and implemention of a flow and congestion integration of such algorithms in the MORE architecture. control algorithm that can cope efficiently with such highly dynamic systems and provide high throughputs. A. Implementation We implemented MORE on Linux. A MORE node consists C. MORE in the Wild of two parts: (1) the relay service and (2) the virtual network Although our measurements indicate, that MORE can interface. For elliptic curve cryptography, we use the Sizzle achieve a performance similar to the Tor anonymous router, code [25] which is part of the OpenSSL library. only a deployment can evaluate the proposed design fully. To relay a packet in the MORE network, it needs to contain Thus, we are currently deploying MORE on hosts at univer- information about the next relay on the path, e.g. its IP address sities in various European countries. and the port number. Furthermore, the packet needs to contain the key the decrypt all this information, i.e. to remove one VI.FUTURE WORKAND CONCLUSION layer of encryption. In this paper, we present a novel approach to anonymous IP address and port account for six bytes. With the 192 bit Internet communication: dynamic multipath Onion Routing. ECC key and one reserved byte, this information fits into a MORE routes each packet along a different path in an IP DNS resolve Get path to freespeech.anon freespeech.anon ry e

Relays c o

DNS reply 10.2.3.79

Relays Servi Direct r server HTTP/1.1

e Virtual IP and n anonymous path sections TCP data request Path through

TCP data request us web RE RE eech.ano b brows

to 10.2.3.79 relay cascade o p

e from 10 .20 . 4. 77 O O M M ww.frees lice’s w lice’s anonym w A TCP data reply Path through TCP data reply to 10.20.4.77 relay cascade from 10.2.3.79 Bob’s ET http:// ET G Bob Alice Virtual IP: 10.2.3.79 Virtual IP: 10.20.4.77 www.freespeech.anon

Fig. 4. Seamless integration of existing applications into the anonymous communication scheme: in this example, Alice uses a web browser to request the site http://www.freespeech.anon from an anonymous web server.

overlay. Compared to existing Onion Routers, MORE is not [11] A. Mislove, G. Oberoi, A. Post, C. Reis, P. Druschel, and D. Wallach, susceptible to pattern and timing based attacks and reduces “AP3: A cooperative, decentralized service providing anonymous com- munication,” in Proc. of ACM SIGOPS European Workshop, September the impact of overloaded relays. Its transparent architecture 2004. and name service allows a seamless integration of existing [12] L. Zhuang, F. Zhou, B. Y. Zhao, and A. Rowstron, “Cashmere: Resilient applications without changes to the applications or communi- Anonymous Routing,” in Proc. of Symposium on Networked Systems Design and Implementation (NSDI), May 2005. cation protocols. MORE is implemented transparently in the [13] S. Katti, J. Cohen, and D. Katabi, “Information slicing: Anonymity using network stack via virtual IP addresses. unreliable overlays,” in Proc. of the 4th USENIX Symposium on Network Elliptic curve cryptography and key caching reduce the Systems Design and Implementation (NSDI), April 2007. [14] A. Fasbender, D. Kesdogan, and O. Kubitz, “Analysis of security and header and performance overhead and make the MORE im- privacy in mobile ip,” in Proc. of 4 the International Conference on plementation feasible. Our evaluation shows that MORE can Telecommunication Systems Modeling and Analysis, March 1996. reach a throughput similar to the Tor anonymous router while [15] ——, “Variable and scalable security: Protection of location information in mobile ip,” in Proc. of 46th IEEE Vehicular Technology Society providing a more flexible routing paradigm. Conference (VTC), April 1996. [16] A. Serjantov and S. J. Murdoch, “Message Splitting Against the Partial Adversary,” in Proc. of Privacy Enhancing Technologies workshop REFERENCES (PET), May 2005. [17] G. Danezis, R. Dingledine, and N. Mathewson, “: Design [1] P. F. Syverson, D. M. Goldschlag, and M. G. Reed, “Anonymous of a Type III Protocol,” in Proc. of the IEEE Connections and Onion Routing,” in IEEE Symposium on Security and Symposium on Security and Privacy, May 2003. Privacy, Feb. 1997. [18] U. Moller,¨ L. Cottrell, P. Palfrader, and L. Sassaman, “Mixmaster [2] S. J. Murdoch and G. Danezis, “Low-Cost Traffic Analysis of TOR,” in Protocol — Version 2,” Draft, July 2003. Proc. of the IEEE Symposium on Security and Privacy, May 2005. [19] V. Gupta, D. Stebila, S. Fung, S. C. Shantz, N. Gura, and H. Eberle, [3] L. Overlier and P. Syverson, “Locating Hidden Servers,” in Proc. of “Speeding up Secure Web Transactions Using Elliptic Curve Cryp- IEEE Symposium on Security and Privacy (SP), May 2006. tography,” in Proc. of the Network and Distributed System Security [4] S. J. Murdoch, “Hot or not: revealing hidden services by their Symposium (NDSS), February 2004. skew,” in Proc. of 13th ACM conference on Computer and communica- [20] O. Landsiedel, A. Pimenidis, K. Wehrle, H. Niedermayer, and G. Carle, tions security(CCS), October 2006. “Security Considerations for Dynamic Multipath Onion Routing,” Draft, [5] D. L. Chaum, “Untraceable electronic mail, return addresses, and digital March 2007. [Online]. Available: http://ds.cs.rwth-aachen.de/research/ ,” Communications of ACM, Feb. 1981. projects/more/more security/download [21] H. Han, S. Shakkottai, C. V. Hollot, R. Srikant, and D. Towsley, “Multi- [6] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The Second- path tcp: a joint congestion control and routing scheme to exploit path Generation Onion Router,” in Proc. of 13th USENIX Security Sympo- diversity in the internet,” IEEE/ACM Trans. Netw., 2006. sium, August 2004. [22] F. Kelly and T. Voice, “Stability of end-to-end algorithms for joint [7] P. Boucher, A. Shostack, and I. Goldberg, “Freedom Systems 2.0 routing and rate control,” SIGCOMM Comput. Commun. Rev., 2005. Architecture,” Zero Knowledge Systems, Inc., White Paper, Dec. 2000. [23] H. Han, S. Shakkottai, C. Hollot, R. Srikant, and D. Towsley, “Overlay [8] O. Berthold, H. Federrath, and S. Kopsell,¨ “Web MIXes: A system for tcp for multi-path routing and congestion control,” in Proc. of ENS- anonymous and unobservable Internet access,” in Proc. of Designing Pri- INRIA ARC-TCP Workshop, 2003. vacy Enhancing Technologies: Workshop on Design Issues in Anonymity [24] P. Key and L. Massouli, “Combining multipath routing and congestion and Unobservability, July 2000. control for robustnes,” in Proc. of 40th IEEE Conference on Information [9] M. Rennhard and B. Plattner, “Introducing MorphMix: Peer-to-Peer Sciences and Systems (CISS), March 2006. based Anonymous Internet Usage with Collusion Detection,” in Proc. of [25] V. Gupta, M. Millard, S. Fung, Y. Zhu, N. Gura, H. Eberle, and S. C. Workshop on Privacy in the Electronic Society (WPES), Nov. 2002. Shantz, “Sizzle: A Standards-Based End-to-End Security Architecture [10] M. J. Freedman and R. Morris, “Tarzan: A Peer-to-Peer Anonymizing for the Embedded Internet,” in Proc. of IEEE International Conference Network Layer,” in Proc. of 9th ACM Conference on Computer and on Pervasive Computing and Communications (PerCom), March 2004. Communications Security (CCS), Nov. 2002.