The Pynchon Gate
Total Page:16
File Type:pdf, Size:1020Kb
The Pynchon Gate A Secure Method of Pseudonymous Mail Retrieval Len Sassaman Bram Cohen Nick Mathewson Katholieke Universiteit Leuven BitTorrent The Free Haven Project [email protected] [email protected] [email protected] ABSTRACT ter [48] or Mixminion [22]) to send authenticated requests to We describe the Pynchon Gate, a practical pseudonymous a nym server, which delivers outgoing messages to the email message retrieval system. Our design uses a simple distributed- network and handles administrative commands. The nym trust private information retrieval protocol to prevent ad- server also receives incoming messages and passes them to a versaries from linking recipients to their pseudonyms, even collator component, which encrypts the messages and peri- when some of the infrastructure has been compromised. This odically packages them into regular batches. These batches approach resists global traffic analysis significantly better are then replicated at a number of distributor servers, which than existing deployed pseudonymous email solutions, at the use a private information retrieval protocol to allow nym cost of additional bandwidth. We examine security concerns owners to receive mail while maintaining unlinkability be- raised by our model, and propose solutions. tween a message and its recipient. 1.0.1 Goals. Categories and Subject Descriptors First, our design must be secure: we want the Pynchon C.2.4 [Distributed Systems]: Client/server Gate to resist active and passive attacks at least as well as General Terms the state of the art for forward message anonymity. Thus, we should try to protect users’ identities from a global eaves- Design, Security dropper for as long as possible; to hinder active attackers Keywords who can delay, delete, or introduce traffic; and to resist an attacker who has compromised some (but not all) of the anonymity, mix networks, private information retrieval servers on the network. In order to provide security, however, we must ensure that 1. INTRODUCTION the system is deployable and usable: since anonymity and Pseudonymous messaging services allow users to send mes- pseudonymity systems hide users among each other, fewer sages that originate at a pseudonymous address (or “nym”) users means less protection [1]. Thus, we should handle node unlinked to the user, and to receive messages sent to that failure without loss of mail; we must not require more band- address, without allowing an attacker to deduce which users width than volunteer servers can provide or users are willing are associated with which pseudonyms. These systems can to use; and we should not require a complicated interface. be used for parties to communicate without revealing their identities, or can be used as a building-block for other sys- 1.0.2 In this paper. tems that need a bi-directional anonymous communication We begin in Section 2 with a discussion of related work, channel, such as Free Haven [27]. But, as we will argue be- and an overview of known attacks against existing pseudo- low, most existing deployed solutions are either vulnerable nymity systems. (To motivate our work, Subsection 4.2 to traffic analysis or require unacceptably large amounts of presents new analysis on the effectiveness of passive traf- bandwidth and storage as the number of users and volume fic analysis against current reply-block based nym servers.) of traffic increase. Section 3 presents the Pynchon Gate in more detail, describ- We propose the Pynchon Gate, a design that uses private ing its organization, design rationales, and network formats. information retrieval (PIR) [13] primitives to build a secure, We describe our simple PIR protocol in subsection 3.4.1. In fault-tolerant pseudonymous mail retrieval system. Section 4 we analyze security, and in Section 5 we discuss In our system, pseudonymous users (or “nym holders”) optimizations and compare our performance to that of other use an existing anonymous email network (such as Mixmas- pseudonymous message systems. We close with an evalua- tion of our design in Section 6. Permission to make digital or hard copies of all or part of this work for 2. BACKGROUND personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies Here we present a brief outline of existing pseudonymity bear this notice and the full citation on the first page. To copy otherwise, to solutions and discuss their limitations and attacks against republish, to post on servers or to redistribute to lists, requires prior specific them. permission and/or a fee. WPES’05, November 7, 2005, Alexandria, Virginia, USA. Copyright 2005 ACM 1-59593-228-3/05/0011 ...$5.00. 2.1 Related Work messages share the same anonymity set, and recent work First, we discuss existing designs for pseudonymous mes- has been done by Danezis and Laurie on attack-resistant sage delivery. Many assume the existence of a “forward” anonymous packet formats suitable for reply messages [23]. anonymous channel that a sender can use to send a mes- However, since reply blocks are still used, reliability issues sage to a known recipient while preventing the recipient, remain: if any given node in the pre-selected SURB’s path the infrastructure, and any attackers from knowing who is is defunct during the interval in which the mail is to be communicating with whom. Currently deployed designs are delivered, the mail is lost. Reply block systems are also based on Chaum’s mix [12] architecture, and include the susceptible to intersection attacks [8]: a global observer can Mixmaster [48] and Mixminion [22] anonymous remailer net- collect data on who is sending and receiving mail, and given works. It is trivial to use these systems to send pseudony- enough time and data, can reliably determine who is talking mous messages: the sender can make an anonymous message to whom [19]. pseudonymous by signing it with a public key associated with her pseudonym. Thus, these designs focus on how to 2.1.3 Network-level client anonymity. receive messages sent to a pseudonymous address. The ZKS Freedom Network [9] provided anonymous ac- Other descriptions of the use of PIR in preserving recipi- cess to a POP3 server [47], enabling its users to maintain ent anonymity have been independently proposed but not pseudonyms using standard email protocols. Freedom was deployed. Earlier work by Jim McCoy describes a simi- discontinued due to high operating expenses, especially in lar architecture to the Pynchon Gate, but does not use an bandwidth. Other network-level anonymity systems, such as information-theoretic primitive for preserving privacy [46]. Pipenet [18], Onion Routing [33], the Java Anon Proxy [7], Independent work by Cooper and Birman [15] describes a or Tor [28], could be used in much the same fashion; un- PIR-based message service for mobile computing systems, fortunately, they face the same barriers to widespread de- and Berthold, et al. have presented work [6] which shows ployment [32]. Attempts to address the practical barriers to that simple optimizations to the PIR protocol are possible. deployment of low-latency anonymity systems have resulted in designs which are at greater risk to traffic analysis meth- 2.1.1 Reply blocks and return addresses. ods such as end-to-end timing attacks [21, 20, 49, 25] It is In 1981, Chaum [12] described a method of using return possible that such a low-latency system may be developed addresses in mix-nets: recipients encode a reply path, and which is both secure against end-to-end analysis and cost- allow senders to affix messages to the encoded path. As the effective to operate, but no such system has yet been proven message moves through the network, the path is decoded feasible. and the message encoded at each hop, until an encoded mes- sage reaches its eventual recipient. This system relies upon 2.1.4 Network-level server anonymity. all selected component nodes of the chosen path remaining The second generation implementation of Onion Routing, operational in order for mail to be delivered, which can make Tor [28], implements rendezvous points [31] that allow users the system too unreliable for practical use if significant time to offer location-hidden services. A user wishing to anony- elapses between path generation and message origination.1 mously receive messages can use this to receive mail at a In addition to reliability issues, some implementations of hidden location: messages are delivered to the server over these “reply blocks” suffer from a pseudonym management the Onion Routing network, and successful delivery does not perspective. Cypherpunk nym servers based on the first gen- require the sender to know the IP address of the destination eration implementation of Chaum’s mix-nets (Type I remail- server. ers [29]), such as alpha.c2.net [3] and nym.alias.net [45], Rendezvous points offer an alternative method of lever- implement a central reply-block repository that allowed the aging network-level anonymity systems for anonymous mail pseudonym holders to receive messages delivered to a email receipt; however, they do not address the previously men- address. Unfortunately, Type I remailers allow multiple uses tioned concerns with these anonymity systems. of their reply blocks, which are vulnerable to replay and flooding attacks as discussed in [16, 44]. Type II (Mixmas- 2.1.5 Re-encryption mixes. ter) and Type III (Mixminion [22]) systems do not permit Re-encryption mixes [35] aim to improve the reliability multiple-use reply blocks, and prevent replay attacks [17]. of anonymous message systems. Recent work has shown that re-encryption mixes can be used to facilitate anony- 2.1.2 Single-use reply blocks. mous message replies [34]. While reusable anonymous re- While the Type II system does not support anonymous turn channels in re-encryption mixes do improve on the reply blocks, the Type III (Mixminion) system introduces robustness of simple reply blocks in a Chaumian mix-net, single-use reply blocks (SURBs) [39] to avoid replay attacks.