We present Tor, a circuit-based low-latency anonymous communication service. This second-generation Onion Routing system addresses limitations in the original design by adding perfect forward secrecy, congestion control, directory servers, integrity checking, configurable exit policies, and a practical design for location-hidden services via rendezvous points. Tor works on the real-world Internet, requires no special privileges or kernel modifications, requires little synchronization or coordination between nodes, and provides a reasonable tradeoff between anonymity, usability, and efficiency. We briefly describe our experiences with an international network of more than 30 nodes. We close with a list of open problems in anonymous communication.

/pdf/tor-the-second-generation-onion-router-2qfrg0ppqb.pdf

Tor: the second-generation onion router

Digital audio, video, images, and documents are flying through cyberspace to their respective owners. Unfortunately, along the way, individuals may choose to intervene and take this content for themselves. Digital watermarking and steganography technology greatly reduces the instances of this by limiting or eliminating the ability of third parties to decipher the content that he has taken. The many techiniques of digital watermarking (embedding a code) and steganography (hiding information) continue to evolve as applications that necessitate them do the same. The authors of this second edition provide an update on the framework for applying these techniques that they provided researchers and professionals in the first well-received edition. Steganography and steganalysis (the art of detecting hidden information) have been added to a robust treatment of digital watermarking, as many in each field research and deal with the other. New material includes watermarking with side information, QIM, and dirty-paper codes. The revision and inclusion of new material by these influential authors has created a must-own book for anyone in this profession.

*This new edition now contains essential information on steganalysis and steganography
*New concepts and new applications including QIM introduced
*Digital watermark embedding is given a complete update with new processes and applications

Digital Watermarking and Steganography

Bit coin is the first digital currency to see widespread adoption. While payments are conducted between pseudonyms, Bit coin cannot offer strong privacy guarantees: payment transactions are recorded in a public decentralized ledger, from which much information can be deduced. Zero coin (Miers et al., IEEE SaP 2013) tackles some of these privacy issues by unlinking transactions from the payment's origin. Yet, it still reveals payments' destinations and amounts, and is limited in functionality. In this paper, we construct a full-fledged ledger-based digital currency with strong privacy guarantees. Our results leverage recent advances in zero-knowledge Succinct Non-interactive Arguments of Knowledge (zk-SNARKs). First, we formulate and construct decentralized anonymous payment schemes (DAP schemes). A DAP scheme enables users to directly pay each other privately: the corresponding transaction hides the payment's origin, destination, and transferred amount. We provide formal definitions and proofs of the construction's security. Second, we build Zero cash, a practical instantiation of our DAP scheme construction. In Zero cash, transactions are less than 1 kB and take under 6 ms to verify - orders of magnitude more efficient than the less-anonymous Zero coin and competitive with plain Bit coin.

/pdf/zerocash-decentralized-anonymous-payments-from-bitcoin-3npbm68ga9.pdf

Zerocash: Decentralized Anonymous Payments from Bitcoin

Besides attracting a billion dollar economy, Bitcoin revolutionized the field of digital currencies and influenced many adjacent areas. This also induced significant scientific interest. In this survey, we unroll and structure the manyfold results and research directions. We start by introducing the Bitcoin protocol and its building blocks. From there we continue to explore the design space by discussing existing contributions and results. In the process, we deduce the fundamental structures and insights at the core of the Bitcoin protocol and its applications. As we show and discuss, many key ideas are likewise applicable in various other fields, so that their impact reaches far beyond Bitcoin itself.

Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies

Federated learning (FL) is a machine learning setting where many clients (e.g. mobile devices or whole organizations) collaboratively train a model under the orchestration of a central server (e.g. service provider), while keeping the training data decentralized. FL embodies the principles of focused data collection and minimization, and can mitigate many of the systemic privacy risks and costs resulting from traditional, centralized machine learning and data science approaches. Motivated by the explosive growth in FL research, this paper discusses recent advances and presents an extensive collection of open problems and challenges.

Advances and Open Problems in Federated Learning

We present Mixminion, a message-based anonymous remailer protocol with secure single-use reply blocks. Mix nodes cannot distinguish Mixminion forward messages from reply messages, so forward and reply messages share the same anonymity set. We add directory servers that allow users to learn public keys and performance statistics of participating remailers, and we describe nymservers that provide long-term pseudonyms using single-use reply blocks as a primitive. Our design integrates link encryption between remailers to provide forward anonymity. Mixminion works in a real-world Internet environment, requires little synchronization or coordination between nodes, and protects against known anonymity-breaking attacks as well as or better than other systems with similar design parameters.

/pdf/mixminion-design-of-a-type-iii-anonymous-remailer-protocol-4tx21i8clc.pdf

Mixminion: design of a type III anonymous remailer protocol

We extend earlier research on mounting and resisting passive long-term end-to-end traffic analysis attacks against anonymous message systems, by describing how an eavesdropper can learn sender-receiver connections even when the substrate is a network of pool mixes, the attacker is non-global, and senders have complex behavior or generate padding messages. Additionally, we describe how an attacker can use information about message distinguishability to speed the attack. We simulate our attacks for a variety of scenarios, focusing on the amount of information needed to link senders to their recipients. In each scenario, we show that the intersection attack is slowed but still succeeds against a steady-state mix network. We find that the attack takes an impractical amount of time when message delivery times are highly variable; when the attacker can observe very little of the network; and when users pad consistently and the adversary does not know how the network behaves in their absence.

/pdf/practical-traffic-analysis-extending-and-resisting-qhpmrs22ov.pdf

Practical traffic analysis: extending and resisting statistical disclosure

A growing field of literature is studying how usability impacts security [4]. One class of security software is anonymizing networks— overlay networks on the Internet that provide privacy by letting users transact (for example, fetch a web page or send an email) without revealing their communication partners. In this position paper we focus on the network effects of usability on privacy and security: usability is a factor as before, but the size of the user base also becomes a factor. We show that in anonymizing networks, even if you were smart enough and had enough time to use every system perfectly, you would nevertheless be right to choose your system based in part on its usability for other users. 1 Usability for others impacts your security While security software is the product of developers, the security it provides is a collaboration between developers and users. It’s not enough to make software that can be used securely—software that is hard to use often suffers in its security as a result. For example, suppose there are two popular mail encryption programs: HeavyCrypto, which is more secure (when used correctly), and LightCrypto, which is easier to use. Suppose you can use either one, or both. Which should you choose? You might decide to use HeavyCrypto, since it protects your secrets better. But if you do, it’s likelier that when your friends send you confidential email, they’ll make a mistake and encrypt it badly or not at all. With LightCrypto, you can at least be more certain that all your friends’ correspondence with you will get some protection. What if you used both programs? If your tech-savvy friends use HeavyCrypto, and your less sophisticated friends use LightCrypto, then everybody will get as much protection as they can. But can all your friends really judge how able they are? If not, then by supporting a less usable option, you’ve made it likelier that your non-savvy friends will shoot themselves in the foot. The crucial insight here is that for email encryption, security is a collaboration between multiple people: both the sender and the receiver of a secret email must work together to protect its confidentiality. Thus, in order to protect your own security, you need to make sure that the system you use is not only usable by yourself, but by the other participants as well. This observation doesn’t mean that it’s always better to choose usability over security, of course: if a system doesn’t address your threat model, no amount of usability can make it secure. But conversely, if the people who need to use a system can’t or won’t use it correctly, its ideal security properties are irrelevant. Hard-to-use programs and protocols can hurt security in many ways: • Programs with insecure modes of operation are bound to be used unknowingly in those modes. • Optional security, once disabled, is often never re-enabled. For example, many users who ordinarily disable browser cookies for privacy reasons wind up re-enabling them so they can access sites that require cookies, and later leaving cookies enabled for all sites. • Badly labeled off switches for security are even worse: not only are they more prone to accidental selection, but they’re more vulnerable to social attackers who trick users into disabling their security. As an example, consider the page-long warning your browser provides when you go to a website with an expired or otherwise suspicious SSL certificate. • Inconvenient security is often abandoned in the name of day-to-day efficiency: people often write down difficult passwords to keep from forgetting them, and share passwords in order to work together. • Systems that provide a false sense of security prevent users from taking real measures to protect themselves: breakable encryption on ZIP archives, for example, can fool users into thinking that they don’t need to encrypt email containing ZIP archives. • Systems that provide bad mental models for their security can trick users into believing they are more safe than they really are: for example, many users interpret the “lock” icon in their web browsers to mean “You can safely enter personal information,” when its meaning is closer to “Nobody can read your information on its way to the named website.” 2 Usability is even more important for privacy We described above that usability affects security in systems that aim to protect data confidentiality. But when the goal is privacy, it can become even more important. Anonymizing networks such as Tor [8], JAP [3], Mixminion [6], and Mixmaster [12] aim to hide not only what is being said, but also who is communicating with whom, which users are using which websites, and so on. These systems have a broad range of users, including ordinary citizens who want to avoid being profiled for targeted advertisements, corporations who don’t want to reveal information to their competitors, and law enforcement and government intelligence agencies who need to do operations on the Internet without being noticed. 1 Or more accurately, “Nobody can read your information on its way to someone who was able to convince one of the dozens to hundreds of CAs configured in your browser that they are the named website, or who was able to compromise the named website later on. Unless your computer has been compromised already.” Anonymity networks work by hiding users among users. An eavesdropper might be able to tell that Alice, Bob, and Carol are all using the network, but should not be able to tell which of them is talking to Dave. This property is summarized in the notion of an anonymity set—the total set of people who, so far as the attacker can tell, might be the one engaging in some activity of interest. The larger the set, the more anonymous the participants. When more users join the network, existing users become more secure, even if the new users never talk to the existing ones! [1, 2] Thus, “anonymity loves company.” In a data confidentiality system like PGP, Alice and Bob can decide by themselves that they want to get security. As long as they both use the software properly, no third party can intercept the traffic and break their encryption. However, Alice and Bob can’t get anonymity by themselves: they need to participate in an infrastructure that coordinates users to provide cover for each other. No organization can build this infrastructure for its own sole use. If a single corporation or government agency were to build a private network to protect its operations, any connections entering or leaving that network would be obviously linkable to the controlling organization. The members and operations of that agency would be easier, not harder, to distinguish. Thus, to provide anonymity to any of its users, the network must accept traffic from external users, so the various user groups can blend together. In practice, existing commercial anonymity solutions (like Anonymizer.com) are based on a set of single-hop proxies. In these systems, each user connects to a single proxy, which then relays the user’s traffic. Single proxies provide comparatively weak security, since a compromised proxy can trivially observe all of its users’ actions, and an eavesdropper only needs to watch a single proxy to perform timing correlation attacks against all its users’ traffic. Worse, all users need to trust the proxy company to have good security itself as well as to not reveal user activities. The solution is distributed trust: an infrastructure made up of many independently controlled proxies that work together to make sure no transaction’s privacy relies on any single proxy. With distributed-trust anonymity networks, users build tunnels or circuits through a series of servers. They encrypt their traffic in multiple layers of encryption, and each server removes a single layer of encryption. No single server knows the entire path from the user to the user’s chosen destination. Therefore an attacker can’t break the user’s anonymity by compromising or eavesdropping on any one server. 2 Assuming that all participants are equally plausible, of course. If the attacker suspects Alice, Bob, and Carol equally, Alice is more anonymous than if the attacker is 98% suspicious of Alice and 1% suspicious of Bob and Carol, even though the anonymity sets are the same size. Because of this imprecision, research is moving beyond simple anonymity sets to more sophisticated measures based on the attacker’s confidence [7, 14]. 3 This catch-phrase was first made popular in our context by the authors of the Crowds [13] anonymity network. Despite their increased security, distributed-trust anonymity networks have their disadvantages. Because traffic needs to be relayed through multiple servers, performance is often (but not always) worse. Also, the software to implement a distributed-trust anonymity network is significantly more difficult to design and implement. Beyond these issues of the architecture and ownership of the network, however, there is another catch. For users to keep the same anonymity set, they need to act like each other. If Alice’s client acts completely unlike Bob’s client, or if Alice’s messages leave the system acting completely unlike Bob’s, the attacker can use this information. In the worst case, Alice’s messages stand out entering and leaving the network, and the attacker can treat Alice and those like her as if they were on a separate network of their own. But even if Alice’s messages are only recognizable as they leave the network, an attacker can use this information to break exiting messages into “messages from User1,” “messages from User2,” and so on, and can now get away with linking messages to their senders as groups, rather than trying to guess from individual messages [6, 11]. Some of this partitioning is inevitable: if Alice speaks Arabic and Bob speaks Bulgarian, we can’t force them both to learn English in order to mask each other. What does this imply for usability? More so than with encryption systems, 

https://freehaven.net/~arma/slides-weis06.pdf

Anonymity Loves Company: Usability and the Network Effect.

Decentralized anonymity systems tend to be unreliable, because users must choose nodes in the network without knowing the entire state of the network. Reputation systems promise to improve reliability by predicting network state. In this paper we focus on anonymous remailers and anonymous publishing, explain why the systems can benefit from reputation, and describe our experiences designing reputation systems for them while still ensuring anonymity. We find that in each example we first must redesign the underlying anonymity system to support verifiable transactions.

/pdf/reputation-in-p2p-anonymity-systems-z1lrjiuvww.pdf

Nick Mathewson

Papers

Tor: the second-generation onion router

Mixminion: design of a type III anonymous remailer protocol

Practical traffic analysis: extending and resisting statistical disclosure

Anonymity Loves Company: Usability and the Network Effect.

Reputation in P2P Anonymity Systems