On Privacy Notions in Anonymous Communication
Christiane Kuhn, Martin Beck, Stefan Schiffner, Eduard Jorswieck,, Thorsten Strufe
TL;DR
This paper develops a formal framework for analyzing privacy notions in anonymous communication networks, enabling comparison, hierarchy, and integration of various existing privacy definitions and assumptions.
Contribution
It introduces a comprehensive formal analysis framework that captures, compares, and extends privacy notions and assumptions in ACNs, unifying prior ad hoc definitions.
Findings
Established a hierarchy of privacy notions.
Formalized privacy goals and their relationships.
Integrated various existing frameworks into a unified model.
Abstract
Many anonymous communication networks (ACNs) with different privacy goals have been developed. However, there are no accepted formal definitions of privacy and ACNs often define their goals and adversary models ad hoc. However, for the understanding and comparison of different flavors of privacy, a common foundation is needed. In this paper, we introduce an analysis framework for ACNs that captures the notions and assumptions known from different analysis frameworks. Therefore, we formalize privacy goals as notions and identify their building blocks. For any pair of notions we prove whether one is strictly stronger, and, if so, which. Hence, we are able to present a complete hierarchy. Further, we show how to add practical assumptions, e.g. regarding the protocol model or user corruption as options to our notions. This way, we capture the notions and assumptions of, to the best of our…
Click any figure to enlarge with its caption.
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10| Symbol | Description | Translation to Game |
|---|---|---|
| Message Length | Messages in the two scenarios always have the same length. | |
| Everything but Senders | Everything except the senders is identical in both scenarios. | |
| Everything but Receivers/Messages | Analogous | |
| Everything but Senders and Messages | Everything except the senders and messages is identical in both scenarios. | |
| Analogous | Analogous | |
| Something is sent | In every communication something must be sent ( not allowed). | |
| Nothing | Nothing will be checked; always true. | |
| Active Senders/Receivers | Who sends/receives is equal for both scenarios. | |
| Sender/Receiver Frequencies | Which sender/receiver sends/receives how often is equal for both scenarios. | |
| Number of Senders/ Receivers | How many senders/receivers communicate is equal for both scenarios. | |
| Message Partitioning per Sender/Receiver | Which messages are sent/received from the same sender/receiver is equal for both scenarios. | |
| Sender/Receiver Frequency Histograms | How many senders/receivers send/receive how often is equal for both scenarios. |
| Notion | Properties |
|---|---|
| etc. | analogous |
| etc. | analogous |
| Properties of , remove | |
| for | |
| analogous | |
| Usage | Explanation |
|---|---|
| Dimension Sender, Receiver, Message | |
| Dimension not mentioned | Dimension can leak |
| Dimension mentioned | Protection focused on this dimension exists |
| not even the participating items regarding D leak,(e.g. : not even leaks) | |
| participating items regarding D can leak, but not which exists how often (e.g. : leaks, but not ) | |
| participating items regarding D and how often they exist can leak ( e.g. : leaks) | |
| like X but additionally Prop can leak | |
| uses ; participating items regarding do not leak, (e.g. : ) | |
| uses ; participating items regarding can leak, (e.g. : ) | |
| uses ; it can leak whether two participating item regarding are the same, (e.g. : ) | |
| short for | |
| short for | |
| short for | |
| is dominating dimension, usually has more freedom, i.e. is a weaker restriction than | |
| nothing can leak (not even the existence of any communication) |
| Notion | Name | Aspects |
|---|---|---|
| Loopix’s Sender Unobservavility | ||
| Loopix’s Receiver Unobservability | ||
| Restricted Sender Unobservability | ||
| Restricted Receiver Unobservability |
| Symbol | Description |
|---|---|
| Adaptive corruption is allowed. | |
| Only static corruption of users is allowed. | |
| No corruption of users is allowed. | |
| Corrupted users not restricted. | |
| Corrupted users are not allowed to be chosen as senders or receivers. | |
| Corrupted users are not allowed to be senders. | |
| Corrupted users are not allowed to be receivers. | |
| Corrupted users send/receive identical messages in both scenarios. |
| Notion including option | Definition |
|---|---|
| Properties of | |
| , etc. | , etc. |
| Properties of |
| Framework | Notion | Equivalent to |
| AnoA | ||
| 131313Under the assumption that in all cases is communicated like in of [3] and in of one older AnoA version [2]. | ||
| 141414Under the assumption that the receiver in stage 2 can be another than in stage 1 like in of [3]. | ||
| Bohli’s | ||
| analogous | ||
| Hevia’s | , | |
| , | ||
| , | ||
| , | ||
| , | ||
| , | ||
| analogous | ||
| Gelernter’s | , | |
| , | ||
| analogous Hevia: | ||
| analogous Hevia: | ||
| analogous Hevia |
| () | () | = | () | () | () | () | () | () | () | () | () | () | |||||
| () | () | () | = | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | = | () | () | () | () | () | () | () | () | () | () | () | ||
| () | () | () | () | () | = | () | () | () | () | () | () | () | () | () | () | ||
| () | () | () | () | () | () | = | () | () | () | () | () | () | () | () | () | () | |
| () | () | = | |||||||||||||||
| () | () | () | = | () | |||||||||||||
| () | () | () | () | () | = | () | () | () | () | () | |||||||
| () | () | () | () | () | = | ||||||||||||
| () | () | () | () | () | () | = | |||||||||||
| () | () | () | () | () | () | () | () | () | () | = | () | () | () | ||||
| () | () | () | () | () | () | () | () | = | |||||||||
| () | () | () | () | () | () | () | () | () | () | () | () | = | () | () | |||
| () | () | = | |||||||||||||||
| () | () | () | = | ||||||||||||||
| () | () | () | () | () | () | () | |||||||||||
| () | () | () | () | () | () | () | |||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | () | () | () | |||||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | () | ) | () | () | () | () | () | |
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | |||||||||||||
| = | |||||||||||||||||
| = | () | ||||||||||||||||
| () | = | () | () | ||||||||||||||
| () | = | () | () | ||||||||||||||
| () | = | () | () | ||||||||||||||
| () | = | () | () | ||||||||||||||
| () | = | () | () | () | |||||||||||||
| () | = | () | () | ||||||||||||||
| () | = | () | () | () | |||||||||||||
| () | () | () | () | () | () | () | () | () | = | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | = | () | () | () | () | () | ||
| () | () | () | () | () | () | () | () | () | () | () | = | () | () | () | () | () | |
| () | () | () | () | () | () | () | () | () | () | () | () | () | |||||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |
| () | () | () | () | () | |||||||||||||
| () | () | () | () | () | () | ||||||||||||
| () | () | () | () | () | () | ||||||||||||
| () | () | () | () | () | () | ||||||||||||
| () | () | () | () | () | () | ||||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | () | () | () | () | () | ||||||||||||
| () | () | () | () | () | () | () | () | ||||||||||
| () | |||||||||||||||||
| () | |||||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | |||||||||||||||
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | |
| () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () | () |
| attack | ||||
| P | , | |||
| Receiver notions | analogous | analogous | ||
| (S,R) | ||||
| / | Receiver notions | analogous |
| attack | ||||
|---|---|---|---|---|
| - | , | 1. | , | |
| , | ||||
| Receiver notions | analogous |
| output 0 | output 1 | output 1 | output 0 |
|---|
| Symbol | Description |
|---|---|
| Who sends/receives is equal for both scenarios. | |
| Which sender/receiver sends/receives how often is equal for both scenarios. | |
| How many senders/receivers send/receive how often is equal for both scenarios. | |
| Which messages are sent/received from the same sender/receiver is equal for both scenarios. | |
| How many senders/receivers communicate is equal for both scenarios. | |
| Messages in the two scenarios always have the same length. | |
| Everything but the senders is identical in both scenarios. | |
| analogous | |
| Everything but the senders and messages is identical in both scenarios. | |
| analogous | |
| nothing will be checked; always true | |
| If something is sent in both scenarios, the communication is the same. | |
| In every communication something must be sent. | |
| Adversary picks two sender-receiver-pairs. One of the senders and one of the receivers is chosen randomly. For b=0 one of the adversary chosen sender-receiver pairs is drawn. For b=1 the sender is paired with the receiver of the other pair. | |
| analogous | |
| Adversary picks two senders. The other sender might send the second time (stage 2). For b=0 the same sender sends in both stages, for b=1 each sender sends in one of the stages. | |
| analogous | |
| Adversary picks two sender-receiver-pairs. Sender-receiver-pairs might be mixed. For b=0 both adversary chosen sender-receiver-pairs communicate. For b=1 both mixed sender-receiver-pairs communicate. | |
| analogous |
| Symbol | Description |
|---|---|
| Adversary | |
| Challenger | |
| ACN protocol model | |
| Challenge bit | |
| Adversary’s guess | |
| Batch of communications | |
| Communication | |
| Nothing is communicated | |
| is sent from to with auxiliary information | |
| (First) Scenario | |
| Abort game | |
| Challenge rows of batches | |
| Challenge Number | |
| Number of challenge rows allowed in challenge | |
| Number of challenges allowed | |
| Number of challenge rows allowed in game | |
| Set of corrupted users | |
| Set of possible senders | |
| Set of possible receivers |
| Symbol | Description |
|---|---|
| Sender/Message Unobservability with Receiver Unobservability leaking User Number | |
| Sender/Message Unobservability with Receiver Unobservability leaking Histogram | |
| Sender/Message Unobservability with Receiver Unobservability leaking Pseudonym | |
| Sender/Message Unobservability with Receiver-Frequency Unlinkability | |
| Sender/Message Unobservability with Receiver-Frequency Unlinkability leaking Histogram | |
| Sender/Message Unobservability with Receiver-Frequency Unlinkability leaking Pseudonym | |
| Sender/Message Unobservability with Receiver-Message Unlinkability | |
| Sender/Message Unobservability with Receiver-Message Unlinkability leaking Pseudonym | |
| Sender Unobservability | |
| Sender Unobservability leaking User Number | |
| Sender Unobservability leaking Histogram | |
| Sender Unobservability leaking Pseudonym | |
| Sender-Frequency Unlinkability | |
| Sender-Frequency Unlinkability leaking Histogram | |
| Sender-Frequency Unlinkability leaking Pseudonym | |
| Sender-Message Unlinkability | |
| Sender-Message Unlinkability leaking Pseudonym | |
| Sender Unobservability with Message Unobservability leaking Message Length | |
| Twice Sender Unlinkability | |
| Sender-Message Pair Unobservability | |
| Sender-Message Pair Unlinkability | |
| Restricted Sender Unobservability | |
| Receiver notions | analogous |
| Communication Unobservability | |
| Unobservability | |
| Sender-Receiver Unobservability | |
| Message Unobservability with Message Unlinkability | |
| Message Unobservability leaking Message Length | |
| Sender-Receiver Pair Unlinkability | |
| notion, standard assumptions | |
| adaptive corruption | |
| No corruption of users is allowed. | |
| Only static corruption of users is allowed. | |
| Corrupted users are not allowed to be chosen as senders or receivers. | |
| Corrupted users are not allowed to be senders. | |
| Corrupted users are not allowed to be receivers. | |
| Corrupted nodes send/receive identical messages in both scenarios. | |
| Communication of corrupted users not restricted. | |
| Sender and receiver of challenge rows stay the same for this challenge and stage. | |
| Sessions are not restricted. | |
| communications in the two scenarios are allowed to differ. |
| Usage | Explanation |
| Dimension Sender, Receiver, Message | |
| Dimension not mentioned | Dimension can leak |
| Dimension mentioned | Protection focused on this dimension exists |
| not even the participating items regarding D leak,(e.g. : not even leaks) | |
| participating items regarding D can leak, but not which exists how often (e.g. : leaks, but not ) | |
| participating items regarding D and how often they exist can leak ( e.g. : leaks) | |
| like X but additionally Prop can leak | |
| uses ; participating items regarding do not leak, (e.g. : ) | |
| uses ; participating items regarding can leak, (e.g. : ) | |
| uses ; it can leak whether two participating item regarding are the same, (e.g. : ) | |
| short for | |
| short for | |
| short for | |
| is dominating dimension, usually has more freedom, i.e. is a weaker restriction than | |
| nothing can leak (not even the existence of any communication) |
| Usage | Explanation |
| Dimension Sender, Receiver, Message | |
| Dimension not mentioned | Dimension can leak |
| Dimension mentioned | Protection focused on this dimension exists |
| not even the participating items regarding D leak,(e.g. : not even leaks) | |
| participating items regarding D can leak, but not which exists how often (e.g. : leaks, but not ) | |
| participating items regarding D and how often they exist can leak ( e.g. : leaks) | |
| like X but additionally Prop can leak | |
| uses ; participating items regarding do not leak, (e.g. : ) | |
| uses ; participating items regarding can leak, (e.g. : ) | |
| uses ; it can leak whether two participating item regarding are the same, (e.g. : ) | |
| short for | |
| short for | |
| short for | |
| is dominating dimension, usually has more freedom, i.e. is a weaker restriction than | |
| nothing can leak (not even the existence of any communication) |
| Notion | Properties |
| etc. | analogous |
| etc. | analogous |
| Properties of , remove | |
| for | |
| analogous, remove | |
| Symbol | Description |
|---|---|
| Who sends/receives is equal for both scenarios. | |
| Which sender/receiver sends/receives how often is equal for both scenarios. | |
| How many senders/receivers send/receive how often is equal for both scenarios. | |
| Which messages are sent/received from the same sender/receiver is equal for both scenarios. | |
| How many senders/receivers communicate is equal for both scenarios. | |
| Messages in the two scenarios always have the same length. | |
| Everything but the senders is identical in both scenarios. | |
| analogous | |
| Everything but the senders and messages is identical in both scenarios. | |
| analogous | |
| nothing will be checked; always true | |
| If something is sent in both scenarios, the communication is the same. | |
| In every communication something must be sent. | |
| Adversary picks two sender-receiver-pairs. One of the senders and one of the receivers is chosen randomly. For b=0 one of the adversary chosen sender-receiver pairs is drawn. For b=1 the sender is paired with the receiver of the other pair. | |
| analogous | |
| Adversary picks two senders. The other sender might send the second time (stage 2). For b=0 the same sender sends in both stages, for b=1 each sender sends in one of the stages. | |
| analogous | |
| Adversary picks two sender-receiver-pairs. Sender-receiver-pairs might be mixed. For b=0 both adversary chosen sender-receiver-pairs communicate. For b=1 both mixed sender-receiver-pairs communicate. | |
| analogous |
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
[1]Christiane Kuhn
On Privacy Notions in Anonymous Communication
Martin Beck
TU Dresden, E-mail: [email protected]
Stefan Schiffner
Université du Luxembourg, E-mail: [email protected]
Eduard Jorswieck
TU Dresden, E-mail: [email protected]
Thorsten Strufe
TU Dresden, E-mail: [email protected]
Abstract
Many anonymous communication networks (ACNs) with different privacy goals have been developed. However, there are no accepted formal definitions of privacy and ACNs often define their goals and adversary models ad hoc. However, for the understanding and comparison of different flavors of privacy, a common foundation is needed. In this paper, we introduce an analysis framework for ACNs that captures the notions and assumptions known from different analysis frameworks. Therefore, we formalize privacy goals as notions and identify their building blocks. For any pair of notions we prove whether one is strictly stronger, and, if so, which. Hence, we are able to present a complete hierarchy. Further, we show how to add practical assumptions, e.g. regarding the protocol model or user corruption as options to our notions. This way, we capture the notions and assumptions of, to the best of our knowledge, all existing analytical frameworks for ACNs and are able to revise inconsistencies between them. Thus, our new framework builds a common ground and allows for sharper analysis, since new combinations of assumptions are possible and the relations between the notions are known.
This is the extended version to “On Privacy Notions in Anonymous Communication” published at PoPETs 2019.*
1 Introduction
With our frequent internet usage of, e.g., social networks, instant messaging, and web browsing, we constantly reveal personal data. Content encryption can reduce the footprint, but metadata (e.g. correspondents’ identities) still leaks. To protect metadata from state and industrial surveillance, a broad variety of anonymous communication networks has emerged; one of the most deployed is Tor [10], but also others, e.g. I2P [17] or Freenet [9], are readily available. Additionally, many conceptual systems, like Mix-Nets [8], DC-Nets [6], Loopix [15] and Crowds [16] have been published.
The published ACNs address a variety of privacy goals. However, many definitions of privacy goals are ad hoc and created for a particular use case. We believe that a solid foundation for future analysis is still missing. This hinders the understanding and comparison of different privacy goals and, as a result, comparison and improvement of ACNs. In general, comparing privacy goals is difficult since their formalization is often incompatible and their naming confusing. This has contributed to a situation where existing informal comparisons disagree: e.g., Sender Unlinkablity of Hevia and Micciancio’s framework [13] and Sender Anonymity of AnoA [3] are both claimed to be equivalent to Sender Anonymity of Pfitzmann and Hansen’s terminology [14], but significantly differ in the protection they actually provide. These naming issues further complicate understanding of privacy goals and hence analysis of ACNs.
To allow rigorous analysis, i.e. provable privacy, of ACNs, their goals need to be unambiguously defined. Similar to the notions of semantic security (like CPA, CCA1, CCA2 [4]) for confidentiality, privacy goals can be formally defined as indistinguishability games. We call such formally defined privacy goals privacy notions. Further, notions need to be compared according to their strength: achieving the stronger notion implies the weaker one. Comparison of notions, and of the ACNs achieving them, is otherwise impossible. To understand the ramifications of privacy goals, we aim at setting all notions into mutual relationships. This means for every pair of notions it must be clear if one is stronger or weaker than the other, or if they have no direct relationship. Such a comparison has already been made for the notions of semantic security [4]. Further, all the assumptions of different existing analysis frameworks, e.g. regarding corruption or specific protocol parts like sessions, have to be unified in one framework to find a common basis for the comparison.
In this work, we introduce such a unified framework. To achieve this, we build on the foundations of existing analytical frameworks [3, 13, 11, 5]. With their preparatory work, we are able to present basic building blocks of privacy notions: observable properties of a communication, that (depending on the notion) must either be protected, i.e. kept private, by the protocol, or are permitted to be learned by the adversary. Defining our notions based on the idea of properties simplifies comparison. Further, we map practitioners’ intuitions to their underlying formal model, justify our choice of notions with exemple use cases for each, and make a sanity check to see that the privacy goals of a current ACN (Loopix [15]) are covered. As a next step, we include assumptions of existing analysis frameworks by defining them similarly as building blocks that can be combined to any notion. Finally, we argue how the notions and assumptions of existing works map to ours.
We compare all identified privacy notions and present a complete proven hierarchy. As a consequence of our comparison, we are able to rectify mapping inconsistencies of previous work and show how privacy notions and data confidentiality interact. Furthermore, the proofs for building the hierarchy include templates in order to compare and add new privacy notions to the established hierarchy, if necessary. As we added the assumptions, our resulting framework captures all the assumptions and notions of the AnoA [3], Hevia and Miccianchio’s [13], Gelernter and Herzberg’s [11] frameworks, captures most and adapts some of Bohli and Pashalidis’s framework [5] and adds missing ones. We capture the assumptions and notions of the other frameworks by demonstrating equivalences between their and our corresponding notion. This removes the constraints of co-existing frameworks and allows to use all options when analyzing an ACN. To make our work more accessible, we included a how-to-use section and intuitions, recommendations and limits of this work in the discussion.
In summary, our main contributions are:
- –
a holistic framework for analyzing ACNs, capturing more notions and assumptions than each existing framework,
- –
the mapping of practitioners’ intuitions to game-based proofs,
- –
the definition of building blocks for privacy notions,
- –
the selection and unified definition of notions,
- –
a complete hierarchy of privacy notions, which simplifies comparison of ACNs,
- –
the resolution of inconsistencies and revision of mistakes in previous (frame)works
- –
the definition of building blocks for assumptions compatible to our notions and
- –
a guide to use the framework and an example of mapping the goals of an ACN into our hierarchy.
**Outline. ** Section 2 contains an introductory example and gives an overview of our paper. In Section 3, we introduce the underlying model and indistinguishability games. In Section 4, we introduce the basic building blocks of privacy notions: properties. In Section 5, we define the privacy notions. In Section 6, we argue our choice of notions. In Section 7, we introduce further assumptions, that can be combined with our notions as options. In Section 8, we explain how results regarding restricted adversaries carry over to our work. In Section 9, we state the relation of our notions to the other existing analytical frameworks. In Section 10, we present the relations between the notions. In Section 11, we explain how to use the framework for analysis. In Section 12, we discuss our results. In Section 13, we conclude our paper and give an outlook.
2 Overview
We start with an example of a use case and the corresponding implicit privacy goal, to then introduce the idea of the related indistinguishability game. We show how such a game works and what it means for a protocol to be secure according to this goal. Furthermore, by adopting the game we sketch how privacy goals can be formalized as notions and provide an intuition for the relations between different goals.
Example: Alice is a citizen of a repressive regime and engaged with a resistance group. Despite the regime’s sanctions on distributing critical content, Alice wants to publish her latest critical findings. A vanilla encryption scheme would reduce Alice’s potential audience and thus does not solve her problem. Hence, she needs to hide the link between the message and herself as the sender. We call this goal sender-message unlinkability.111Usually this is called sender anonymity. However, since the term sender anonymity is overloaded and sometimes also used with a slightly different meaning, we refer to it as sender-message unlinkability, as the message should not be linkable to the sender.
**First attempt. ** We start by presenting an easy game, that at first glance looks like the correct formalization for the goal of the example, but turns out to model an even stronger goal.
For Alice’s safety, the regime should not suspect her of being the sender of a compromising message, otherwise she risks persecution. Thus, we need to show for the applied protection measure, that compared to any other sender of this message, it is not more probable that Alice is the sender. We analyze the worst case: in a group of users, let Charlie be a user for whom the probability of being the sender differs most from Alice’s probability. If even these two are too close to distinguish, Alice is safe, since all other probabilities are closer. Hence, the regime cannot even exclude a single user from its suspects.
We abstract this idea into a game222Similar to indistinguishability games in cryptology [12]., where the adversary aims to distinguish two “worlds” or scenarios. These may only differ in the properties the protocol is required to protect, but within these restrictions the adversary can choose freely, especially the worst case that is easiest for her to distinguish (e.g. in one scenario Alice sends the message, in the other Charlie). Fig. 1 shows such a game.
What the adversary can observe in step 4 depends on her capabilities and area of control. A weak adversary may only receive a message from somewhere, or discover it on a bulletin board. However, a stronger adversary could e.g. also observe the activity on the Internet uplinks of some parties.
The adversary wins the game if she guesses the correct scenario. If she can devise a strategy that allows her to win the game repeatedly with a probability higher than random guessing, she must have learned some information that is supposed to be protected, here the sender (e.g. that Alice is more probable the sender of the message than Charlie), since everything else was identical in both scenarios. Hence, we say that, if the adversary can find such a strategy, we do not consider the analyzed protocol secure regarding the respective privacy goal.
**Why this is too strong. ** As argued, a protocol achieving this goal would help Alice in her use case. However, if an adversary learns who is sending any message with real information (i.e. no random bits/dummy traffic), she can distinguish both scenarios and wins the game. As an example, consider the following two scenarios: (1) Alice and Bob send messages (2) Charlie and Dave send messages. If the adversary can learn the active senders, she can distinguish the scenarios and win the game. However, if she only learns the set of active senders, she may still not know who of the two active senders in the played scenario actually sent the regime-critical content. Thus, a protocol hiding the information of who sent a message within a set of active senders is good enough for the given example. Yet, it is considered insecure regarding the above game, since an adversary can learn the active senders. Hence, the game defines a goal stronger than the required sender-message unlinkability. As the ACN in this case needs to hide the sending activity (the adversary does not know if a certain possible sender was active or not), we call the goal that is actually modeled sender unobservability.
**Correcting the formalization. ** However, we can adjust the game of Fig. 1 to model sender-message unlinkability. We desire that the only information about the communications that differs between the scenarios is who is sending which message. Thus, we allow the adversary to pick scenarios that differ in the senders, but not in the activity of the senders, i.e. the number of messages each active sender sends. This means, we change what the adversary is allowed to submit in step 1 and what the challenger checks in step 2. So, if the adversary now wants to use Alice and Charlie, she has to use both in both scenarios, e.g. (1) Alice sends the critical message, Charlie a benign message and (2) Charlie sends the critical message, Alice the benign message. Hence, given an ACN where this game cannot be won, the adversary is not able to distinguish whether Alice or another active user sent the regime-critical message. The adversary might learn, e.g. that someone sent a regime-critical message and the identities of all active senders (here that Alice and Charlie are active senders). However, since none of this is sanctioned in the above example, Alice is safe, and we say such an ACN provides sender-message unlinkability.
**Lessons learned. ** Depending on the formalized privacy goal (e.g. sender unobservability) the scenarios are allowed to differ in certain properties of the communications (e.g. the active senders) as we have illustrated in two exemple games. Following the standard in cryptology, we use the term privacy notion, to describe such a formalized privacy goal that defines properties to be hidden from the adversary.
Further, the games used to prove the privacy notions only differ in how scenarios can be chosen by the adversary and hence what is checked by the challenger. This also holds for all other privacy notions; they all define certain properties of the communication to be private and other properties that can leak to the adversary. Therefore, their respective games are structurally identical and can be abstracted to define one general game, whose instantiations represent notions. We explain and define this general game in Section 3. We then define the properties (e.g. that the set of active senders can change) in Section 4 and build notions (e.g. for sender unobservability) upon them in Section 5.
Additionally, we already presented the intuition that sender unobservability is stronger than sender-message unlinkability. This is not only true for this example, in fact we prove: every protocol achieving sender unobservability also achieves sender-message unlinkability. Intuitively, if whether Alice is an active sender or not is hidden, whether she sent a certain message or not is also hidden. We will prove relations between our privacy notions in Section 10 and show that the presented relations (depicted in Figure 6) are complete. Before that, we argue our choice of notions in Section 6.
3 Our Game model
Our goal in formalizing the notions as a game is to analyze a given ACN protocol w.r.t. to a notion, i.e. the game is a tool to investigate if an adversary can distinguish two self-chosen, notion-compliant scenarios. Scenarios are sequences of communications. A communication is described by its sender, receiver, message and auxiliary information (e.g. session identifiers) or the empty communication, signaling that nobody wants to communicate at this point. Some protocols might restrict the information flow to the adversary to only happen at specific points in the execution of the protocol, e.g. because a component of the ACN processes a batch of communications before it outputs statistics about them. Therefore, we introduce batches as a sequence of communications, which is processed as a unit before the adversary observes anything333We use the word batch to designate a bunch of communications. Besides this similarity, it is not related to batch mixes.. When this is not needed, batches can always be replaced with single communications.
As explained in Section 2, we do not need to define a complete new game for every privacy goal, since notions only vary in the difference between the alternative scenarios chosen by the adversary. Hence, for a given ACN and notion, our general game is simply instantiated with a model of the ACN, which we call the protocol model, and the notion. The protocol model accepts a sequence of communications as input. Similar to the real implementations the outputs of the protocol model are the observations the real adversary can make. Note, the adversaries in the game and the real world have the same capabilities444A stronger game adversary also implies that the protocol is safer in the real world., but differ in their aims: while the real world adversary aims to find out something about the users of the system, the game adversary merely aims to distinguish the two scenarios she has constructed herself.
In the simplest version of the game, the adversary constructs two scenarios, which are just two batches of communications and sends them to the challenger. The challenger checks that the batches are compliant with the notion. If so, the challenger tosses a fair coin to randomly decide which of the two batches it executes with the protocol model. The protocol model’s output is returned to the game adversary. Based on this information, the game adversary makes a guess about the outcome of the coin toss.
We extend this simple version of the game, to allow the game adversary to send multiple times two batches to the challenger. However, the challenger performs a single coin flip and sticks to this scenario for this game, i.e. it always selects the batches corresponding to the initial coin flip. This allows analyzing for adversaries, that are able to base their next actions in the attack on the observations they made previously.
Further, we allow for user (a sender or receiver) corruption, i.e. the adversary learns the user’s momentary internal state, by sending corrupt queries to the challenger. Note that although the adversary decides on all the communications that happen in the alternative scenarios, she does not learn secret keys or randomness unless the user is corrupted. This allows to add several options for different corruption models to the privacy goals.
To model all possible attacks, we allow the adversary to send protocol queries. This is only a theoretical formalization to reflect what information the adversary gets and what influence she can exercise. These protocol query messages are sent to the protocol model without any changes by the challenger. The protocol model covers the adversary to ensure that everything the real world adversary can do is possible in the game with some query message. For example, protocol query messages can be used to add or remove nodes from the ACN by sending the appropriate message.
As introduced in Section 2, we say that an adversary has an advantage in winning the game, if she guesses the challenger-selected scenario correctly with a higher probability than random guessing. A protocol achieves a certain privacy goal, if an adversary has at most negligible advantages in winning the game.
Formalization
In this subsection, we formalize the game model to conform to the above explanation.
We use to denote the analyzed ACN* protocol model*, for the challenger and for the adversary, which is a probabilistic polynomial time algorithm. Additionally, we use as a placeholder for the specific notion, e.g. sender unobservability, if we explain or define something for all the notions. A communication in is represented by a tuple with a sender , a receiver , a message , and auxiliary information (e.g. session identifiers). Further, we use instead of the communication tuple to represent that no communication occurs. Communications are clustered into batches , with being the -th communication of batch . Note that we use (underlined) to identify batches and (no underline) for single communications. Batches in turn are clustered into scenarios; the first scenario is . A challenge is defined as the tuple of two scenarios . All symbols used so far and those introduced later are summarized in Tables 12 – 14 in Appendix C.
**Simple Game. **
randomly picks challenge bit . 2. 2.
sends a batch query, containing and , to . 3. 3.
checks if the query is valid, i.e. both batches differ only in information that is supposed to be protected according to the analyzed notion . 4. 4.
If the query is valid, inputs the batch corresponding to to . 5. 5.
’s output is handed to . 6. 6.
After processing the information, outputs her guess for .
**Extensions. ** As explained above, there are useful extensions we make to the simple game:
Multiple Batches
Steps 2-5 can be repeated.
User corruption
Instead of Step 2, can also decide to issue a corrupt query specifying a user and receive ’s internal state as output. This might change ’s state, lead to different behavior of in following queries and yield a higher advantage in guessing than before.
Other parts of the adversary model
Instead of Step 2, can also decide to issue a protocol query, containing an input specific to and receive ’s output to it (e.g. the internal state of a router that is corrupted in this moment). This might change ’s state.
**Achieving notion . ** Intuitively, a protocol achieves a notion if any possible adversary has at most negligible advantage in winning the game. To formalize the informal understanding of achieving goal , we need the following denotation. {\text{Pr}[g=\langle\mathcal{A}\bigm{|}Ch(\Pi,X,c,b)\rangle]} describes the probability that (with at most challenge rows, i.e. communications differing in the scenarios) outputs , when is instantiated with and and the challenge bit was chosen to be . With this probability, achieving a notion translates to Definition 1.
Definition 1** (Achieving a notion ).**
An ACN Protocol achieves , iff for all probabilistic polynomial time(PPT) algorithms there exists a negligible such that
[TABLE]
We use a variable , which is referred to as negligible, as an abbreviation when we actually mean a function that is negligible in a security parameter .
Equivalence to Other Definitions
Notice, that this definition is equivalent to
[TABLE]
and
[TABLE]
(1): for all for all ) for all ). To every attack with , we can construct with . Since the definition requires the inequality to hold for all attacks, this is enough to prove that (1) implies the original, the other way is trivial. This is how we construct it: Given attack , we construct by changing the batches of the first with the second scenario. Hence, \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi,X,c,0)\rangle]=\text{Pr}[0=\langle\mathcal{A^{\prime}}\bigm{|}Ch(\Pi,X,c,1)\rangle] and \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi,X,c,1)\rangle]=\text{Pr}[0=\langle\mathcal{A^{\prime}}\bigm{|}Ch(\Pi,X,c,0)\rangle].
(2): To every attack breaking (1), we can construct one with the same probabilities in (2). Given attacker , we construct as the one that changes the batches of the first with the second scenario and inverts the output of . Hence, \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi,X,c,0)\rangle]=\text{Pr}[1=\langle\mathcal{A^{\prime}}\bigm{|}Ch(\Pi,X,c,1)\rangle] and \text{Pr}[1=\langle\mathcal{A}\bigm{|}Ch(\Pi,X,c,0)\rangle]=\text{Pr}[0=\langle\mathcal{A^{\prime}}\bigm{|}Ch(\Pi,X,c,1)\rangle]. Since we can reverse this operations by applying them again, we can also translate in the other direction.
Differential Privacy based Definition
For some use cases, e.g. if the court of your jurisdiction requires that the sender of a critical content can be identified with a minimal probability of a certain threshold e.g. 70%, a non-negligible might be sufficient. Hence, we allow to specify the parameter of and extend it with the allowed number of challenge rows to finally include the well-known concept of differential privacy as AnoA does in the following definition:
Definition 2** (Achieving ).**
An ACN protocol is with , and , iff for all PPT algorithms :
[TABLE]
Notice that describes how close the probabilities of guessing right and wrong have to be. This can be interpreted as the quality of privacy for this notion. While describes the probability with which the -quality can be violated. Hence, every ACN protocol will achieve for any notion , but this result does not guarantee anything, since with probability the -quality is not met.
The first variant can be expressed in terms of the second as achieves , iff is for a negligible and any .
4 Protected Properties
We define properties to specify which information about the communication is allowed to be disclosed to the adversary, and which must be protected to achieve a privacy notion, as mentioned in Section 2. We distinguish between simple and complex properties. Simple properties can be defined with the basic game model already introduced, while complex properties require some extensions to the basic model.
4.1 Simple Properties
We summarize the informal meaning of all simple properties in Table 1 and introduce them in this section.
Assume an ACN aims to hide the sender but discloses message lengths to observers. For this case, we specify the property () that the message length must not differ between the two scenarios, as this information must not help the adversary to distinguish which scenario the challenger chose to play.
Next, we might want an ACN to protect the identity of a sender, as well as any information about who sent a message, but deliberately disclose which messages are received by which receiver, who the receivers are, and potentially other auxiliary information. We hence specify a property () where only the senders differ between the two scenarios555 symbolizes that only this property may vary in the two submitted scenarios and everything else remains equal., to ensure that the adversary in our game can only win by identifying senders. In case the protection of the receiver identities or messages is required, the same can be defined for receivers () or messages ().
Further, we might want the ACN to protect senders and also the messages; leaving the receiver and auxiliary information to be disclosed to the adversary. This is achieved by specifying a property where only senders and messages differ between the two scenarios and everything else remains equal (). Again, the same can be specified for receivers and messages () or senders and receivers ().
Lastly, ACNs might allow the adversary to learn whether a real message is sent or even how many messages are sent. We specify a property (\mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}) that requires real communications in both scenarios, i.e. it never happens that nothing is sent in one scenario but something is sent in the other. We ensure this by not allowing the empty communication ().
However, a very ambitious privacy goal might even require that the adversary learns no information about the communication at all (). In this case, we allow any two scenarios and check nothing.
**Formalizing those Simple Properties. ** In the following definition all simple properties mentioned so far are formally defined. Therefore, we use as symbol for the statement that is always true.
Definition 3** (Properties , , , \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}, ).**
Let the checked batches be , which include the communications and with . We say the following properties are met, iff for all :
[TABLE]
**More Simple Properties: Active Users, Frequencies. ** The properties of Definition 3 are important to formalize privacy, but are by themselves not sufficient. Take the ACN Tor as an example: While the set of active senders is trivially known to their ISPs and the guard nodes, we still require that the senders are unlinkable with the messages they are sending (and their receivers). Similarly, the sending (receiving) frequency of a party may be important and is not formalized yet. To formalize these properties, we use sets that capture which user sent which messages in a certain period, i.e. a batch of communications (and similarly sets to capture which user received which messages). Note that we use primes (′) for the corresponding sets and properties of the receivers.
Definition 4** (Sender-Message Linking).**
We define the sender-message linkings for scenario ( the receiver-message linkings are analogous) as:
[TABLE]
The sets from Definition 4 allow easy identification of who an active sender in this batch was and how often each sent something:
Definition 5** (Active Sender Set, Frequency Set).**
Let the current batch be the -th one. For ( for ) are defined as:
[TABLE]
Recall that we currently define properties for ACNs that allow the adversary to learn which senders are active at different times, or the number of messages they send during some periods, while hiding some other properties (e.g. which messages they have sent). Hence, with the respective sets for active users and user frequencies defined, we need only to request that they are equal in both scenarios:
Definition 6** (Properties , , ).**
We say that the properties ( analogous) are met, iff:
[TABLE]
**More Simple Properties: Message Partitions, Histograms. ** Other interesting properties are which messages came from a given sender and how many senders sent how many messages. If the adversary knows which messages are sent from the same sender, e.g. because of a pseudonym, she might be able to combine information from them all to identify the sender. If she knows how many senders sent how many messages, she knows the sender activity and hence can make conclusions about the nature of the senders.
As before, we introduce auxiliary variables to formally define these two properties. We use to denote the collection of messages that has been sent by the same sender (e.g. linked by a shared pseudonym) in a set of batches, and to denote the union of all these sets of cardinality . The equality of the properties in the two scenarios must pertain throughout all comparable batches in the scenarios. If this were not true, the inequality would help the adversary to distinguish the scenarios without learning the protected information e.g. identifying the sender.
Definition 7** (Multi-Batch-Message Linkings).**
Let the current batch be the -th, , the power set of and the set of all possible senders ( receivers). For and : We define ( for )
- –
the multi-batch-message-sender linking:
* and*
- –
the cardinality restricted multi-batch-message-sender linking: M_{b,I,n}:=\{M\in M_{b,I}\bigm{|}|M|=n\}.
As before, we define auxiliary variables capturing the information that we want to be equal in both scenarios: We define ordered sets specifying which messages are sent from the same user for any set of batches (Message Partition ) and how many users sent how many messages for any set of batches (Histogram ). Therefore, we use a slightly unusual notation: For any set Z, we use to denote the sequence and to denote a sorted sequence of the elements of the power set666For brevity we use to iterate through a sequence. of .
Definition 8** (Message partitions, Histograms).**
Consider the -th batch, . For ( analogous) are defined as:
[TABLE]
Further, we say that properties ( analogous) are met, iff:
[TABLE]
4.2 Complex Properties
So far, we have defined various properties to protect senders, messages, receivers, their activity, frequency and the grouping of messages. However, this is not sufficient to formalize several relevant privacy goals, and we must hence introduce complex properties.
**Learning Sender and Receiver. ** Consider that one aims to hide which sender is communicating with which receiver. Early ACNs like classical Mix-Nets [8], and also Tor [10], already used this goal. Therefore, we want the adversary to win the game only if she identifies both: sender and receiver of the same communication.
An intuitive solution may be to model this goal by allowing the adversary to pick different senders and receivers () in both scenarios (see Fig. 2 (a) for an example). This, however, does not actually model the privacy goal: by identifying only the sender or only the receiver of the communication, the game adversary could tell which scenario was chosen by the challenger. We hence must extend the simple properties and introduce scenario instances to model dependencies.
Scenario instances. We now require the adversary to give alternative instances for both scenarios (Fig. 2 (b)). The challenger chooses the scenario according to the challenge bit, which is picked randomly for every game, and the instance according to the instance bit, which is picked randomly for every challenge.
Formally, we replace steps 2–5 of the game with the following steps:
2.
sends a batch query, containing , , and to .
3.
checks if the query is valid according to the analyzed notion .
4.
If the query is valid and has not already picked an instance bit for this challenge, picks randomly and independent of . Then it inputs the batch corresponding to and to .
5.
’s output is forwarded to .
This allows us to model the goal that the adversary is not allowed to learn the sender and receiver: We allow the adversary to pick two sender-receiver pairs, which she uses as instances for the first scenario. The mixed sender-receiver pairs must then be provided as instances for the second scenario (see Fig. 2 (b)). We thus force the game adversary to provide alternative assignments for each scenario. This way she cannot abuse the model to win the game by identifying only the sender or the receiver. We call this property Random Sender Receiver .
This complex property is still not sufficient to model the situation in, for example, Tor: The adversary can distinguish the scenarios without learning who sent to whom, just by learning which senders and which receivers are active. Hence, we further restrict the adversary picking instances where both senders and both receivers are active by defining the property Mix Sender Receiver . Here, the adversary picks two instances for where her chosen sender-receiver pairs communicate, and two for where the mixed sender-receiver pairs communicate. The two instances simply swap the order in which the pairs communicate (Fig. 2 (c)). This way, we force the adversary to provide alternative assignments for each scenario where both suspected senders and both suspected receivers are active. This combination prevents the adversary from winning the game without learning the information that the real system is actually supposed to protect, i.e. the sender-receiver pair.
**Defining Complex Properties. ** To simplify the formal definition of complex properties, we introduce challenge rows. A challenge row is a pair of communications with the same index that differ in the two scenarios (e.g. with index ). For complex properties, the challenger only checks the differences of the challenge rows in the two scenarios.
Definition 9** (Properties , ).**
Let the given batches be for instances and scenarios , the set of challenge row indexes, for both instances be the sender-receiver-pairs of the first challenge row of the first scenario ()in this challenge . Random Sender Receiver , Mixed Sender Receiver ( analogous) are met, iff:
[TABLE]
[TABLE]
**Linking message senders. ** A final common privacy goal that still cannot be covered is the unlinkability of senders over a pair of messages (Twice Sender Unlinkability). Assume a real world adversary that can determine that the sender of two messages is the same entity. If subsequently she discovers the identity of the sender of one of the messages through a side channel, she can also link the second message to the same individual.
Stages. To model this goal, we need two scenarios (1) both messages are sent by the same sender, and (2) each message is sent by a different sender. Further, the adversary picks the messages for which she wants to decide whether they are sent from the same individual, and which other messages are sent between those two messages. Therefore, we add the concept of stages and ensure that only one sender sends in the challenge rows of stage 1, and in stage 2 either the same sender continues sending () or another sender sends those messages (). This behavior is specified as the property Twice Sender .
Definition 10** (Property ).**
Let the given batches be for instances and scenarios , the current stage, the set of challenge row indexes, for both instances be the sender-receiver-pairs of the first challenge row of the first scenario () in this challenge in stage 1 and the same pairs in stage 2. Twice Sender is met, iff ( analogous):
[TABLE]
Hence, we need to facilitate distinct stages for notions with the complex properties or . Precisely, in step 2 of the game, the adversary is additionally allowed to switch the stages.
Note that the above definition can easily be extended to having more stages and hence, more than two messages for which the adversary needs to decide whether they have originated at the same sender.
This set of properties allows us to specify all privacy goals that have been suggested in literature as privacy notions and additionally all that we consider important. It is of course difficult to claim completeness, as future ACNs may define diverging privacy goals and novel observable properties (or side-channels) may be discovered.
5 Privacy Notions
Given the properties above, we can now set out to express intuitive privacy goals as formal privacy notions. We start by specifying sender unobservability as an example leading to a general definition of our privacy notions.
Recall the first game we defined in Section 2, which corresponds to sender unobservability ( = S(ender) O(bservability)). There, in both scenarios something has to be sent, i.e. we need to specify that sending nothing is not allowed: \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}. Further, both scenarios can only differ in the senders, i.e. we also need the property that everything but the senders is equal: . Hence, we define sender unobservability as S\overline{O}:=$$\mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}$$\land E_{S}. 777Technically already includes \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}. However, to make the differences to other notions more clear, we decide to mention both in the definition.
We define all other notions in the same way:
Definition 11** (Notions).**
Privacy notions are defined as a boolean expression of the properties according to Table 6.
Modeling the notions as a game, the respective challenger verifies all properties (and the later introduced options) of the adversary’s queries. A complete description of the challenger can be found in Appendix A. Further, an example of how the definitions can be represented by using a challenge specific state, which the challenger maintains, is shown in Algorithms 1 and 2 in Appendix B.
6 On the Choice of Notions
The space of possible combinations of properties, and hence of conceivable privacy notions, is naturally large. Due to this, we verify our selection of privacy goals by finding exemple use cases. Additionally, we demonstrate the choice and the applicability of our definition by analyzing the privacy goals of Loopix, an ACN that was recently published. We additionally verify that our privacy notions include those of previous publications that suggest frameworks based on indistinguishability games, and provide a complete mapping in Section 9.
6.1 Example Use Cases for the Notions
We illustrate our notions by continuing the example of an activist group trying to communicate in a repressive regime, although our notions are generally applicable.
Recall the general idea of an indistinguishability game from the examples in Section 2: To prove that an ACN hides certain properties, whatever is allowed to be learned in the actual ACN must not help a game adversary to win. This way, she is forced to win the game solely based on those properties that are required to remain hidden. Therefore, the information allowed to be disclosed cannot be used in the game and hence must be kept identical in both scenarios.
Before giving examples, we need to order the notions. We chose to group them semantically. Our resulting clusters are shown as gray boxes in Figure 6. Horizontally, we categorize notions that focus on receiver or sender protection (Receiver Privacy Notions or Sender Privacy Notions, respectively) or treat both with the same level of importance (Impartial Notions). Inside those categories, we use clusters concerning the general leakage type: Both-side Unobservability means that neither senders, nor receivers or messages should be leaked. Both-side Message Unlinkability means that it should be possible to link neither senders nor receivers to messages. In Sender Observability, the sender of every communication can be known, but not the message she sends or to whom she sends (Receiver and Message Observability analogous). In Sender-Message Linkability, who sends which message can be known to the adversary (Receiver-Message and Sender-Receiver Linkability analogous).
We also want to explain our naming scheme, which we summarize in Table 3. Our notions consider three dimensions: senders, messages and receivers. Each notion restricts the amount of leakage on each of those dimensions. However, only dimensions that are to be protected are part of the notion name. We use , short for unobservability, whenever the set of such existing items of this dimension cannot be leaked to the adversary. E.g. cannot be achieved if the set of senders is leaked. Notions carrying , short for unlinkability, can leak (for sender related notions), but not some other property related to the item. E.g. we use if the frequency cannot be leaked and , if can be leaked, but not the sender-message relation. With a “” we signal that the property can additionally leak to the adversary. We distinguish those properties from and used before as they give another leakage dimension (as illustrated later in the hierarchy). Further, we use parentheses as in to symbolize that if not only one set, but both sets of senders and receivers ( and ) are learned the notion is broken. Analogously, in both sets can be learned but the linking between sender and receiver cannot. For the last missing complex property, we use to symbolize that two senders have to be linked to be the same identity to break this notion.
For readability we add some abbreviations: We use to symbolize unobservability on all three types and we summarize the remaining types in to . symbolizes the notion in which nothing is allowed to leak. Further, we use curly brackets to symbolize that the message cannot be leaked and we put the (in our understanding) non dominating part of the notion in brackets .
6.1.1 Impartial Privacy Notions
These notions treat senders and receivers equally.
**Message Observability. ** The content of messages can be learned in notions of this group, as messages are not considered confidential. Because the real world adversary can learn the content, we must prevent her from winning the game trivially by choosing different content. Hence, such notions use the property that the scenarios are identical except for the senders and receivers () to ensure that the messages are equal in both scenarios.
Example: An activist of the group is already well-known and communication with that person leads to persecution of Alice.
Alice needs a protocol that hides whether a certain sender and receiver communicate with each other; cf. Section 4.2 motivation of the complex property . The resulting notion is Sender-Receiver Pair Unlinkability ().
Example (cont.): *Only few people participate in the protocol. Then, just using the protocol to receive (send) something, when the well known activist is acting as sender (receiver) threatens persecution. *
Alice needs a protocol that hides whether a certain sender and receiver actively participate at the same time or not; cf. Section 4.2 motivation of the complex property . The resulting notion is Sender-Receiver Unobservability ().
**Sender-Receiver Linkability (Message Confidentiality). ** Senders and receivers can be learned in notions of this group, because they are not considered private. Hence, such notions include the property that the scenarios are identical, except for the messages () to ensure that the sender-receiver pairs are equal in both scenarios.
Example: Alice wants to announce her next demonstration. (1) Alice does not want the regime to learn the content of her message and block this event. (2) Further, she is afraid that the length of her messages could put her under suspicion, e.g. because activists tend to send messages of a characteristic length.
In (1) Alice needs a protocol that hides the content of the messages. However, the adversary is allowed to learn all other attributes, in particular the length of the message. Modeling this situation, the scenarios may differ solely in the message content; all other attributes must be identical in both scenarios, as they may not help the adversary distinguish between them. Beyond the above-described , we must thus also request that the length of the messages is identical in both scenarios. The resulting notion is *Message Unobservability leaking Message Length ()*888We stick to our naming scheme here, although we would commonly call this confidentiality..
In the second case (2), the protocol is required to hide the length of the message. The length of the messages thus may differ in the two scenarios, as the protocol will need to hide this attribute. Hence, we remove the restriction that the message length has to be equal in both scenarios from the above notion and end up with Message Unobservability .
**Both-Side Message Unlinkability. ** Notions of this group are broken if the sender-message or receiver-message relation is revealed.
Example: The activists know that their sending and receiving frequencies are similar to regime supporters’ and that using an ACN is in general not forbidden, but nothing else. Even if the content and length of the message () and the sender-receiver relationship () is hidden, the regime might be able to distinguish uncritical from critical communications, e.g. whether two activists communicate “Today” or innocent users an innocent message. In this case, the regime might learn that currently many critical communications take place and improves its measures against the activists.
In this case, the activists want a protocol that hides the communications, i.e. relations of sender, message and receiver. However, as using the protocol is not forbidden and their sending frequencies are ordinary, the adversary can learn which users are active senders or receivers and how often they sent and receive. Modeling this, the users need to have the same sending and receiving frequencies in both scenarios , since it can be learned. However, everything else needs to be protected and hence, can be chosen by the adversary. This corresponds to the notion Message Unobservability with Message Unlinkability ().
**Both-Side Unobservability. ** Even the activity of a certain sender or receiver is hidden in notions of this group.
Example (cont.): It is a risk for the activists, if the regime can distinguish between two leading activists exchanging the message “today” and two loyal regime supporters exchanging the message “tomorrow”.
In this case, Alice wants to disclose nothing about senders, receivers, messages or their combination. However, the adversary can learn the total number of communications happening in the ACN. Modeling this, we need to assure that for every communication in the first scenario, there exists one in the second. We achieve this by prohibiting the use of the empty communication with property \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}. This results in the notion Unobservability ().
Example: The regime knows that a demonstration is close, if the total number of communications transmitted over this protocol increases. It then prepares to block the upcoming event.
To circumvent this, Alice needs a protocol that additionally hides the total number of communications. Modeling this, we need to allow the adversary to pick any two scenarios. Particularly, use of the empty communication is allowed. This is represented in the property that nothing needs to be equal in the two scenarios, , and results in the notion Communication Unobservability (). Note that this is the only notion where the existence of a communication is hidden. All other notions include \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}} and hence do not allow for the use of the empty communication.
6.1.2 Sender (and Receiver) Privacy Notions
These notions allow a greater freedom in picking the senders (or receivers: analogous notions are defined for receivers.).
**Receiver-Message Linkability. ** The receiver-message relation can be disclosed in notions of this group. Hence, such notions include the property that the scenarios are identical except for the senders () to ensure the receiver-message relations are equal in both scenarios.
In Sender-Message Unlinkability () the total number of communications and how often each user sends can be additionally learned. However, who sends which message is hidden. In Sender-Frequency Unlinkability () the set of users and the total number of communications can be additionally disclosed. However, how often a certain user sends is hidden, since it can vary between the two scenarios. In Sender Unobservability (), the total number of communications can additionally be disclosed. However, especially the set of active senders is hidden.
If a notion further includes the following abbreviations, the following information can be disclosed as well:
- –
with User Number Leak (): the number of senders that send something in the scenario
- –
with Histogram Leak (): the histogram of how many senders send how often
- –
with Pseudonym Leak (): which messages are sent from the same user
Example: *Alice is only persecuted when the regime can link a message with compromising content to her – she needs a protocol that at least provides . However, since such a protocol does not hide the message content, the combination of all the messages she sent might lead to her identification. Opting for a protocol that additionally hides the message combination (), i.e. provides , can protect her from this threat.
Further, assuming most users send compromising content, and Alice’s message volume is high, the regime might easily suspect her to be the origin of some compromising messages even if she is careful that the combination of her messages does not reidentify her – she needs a protocol that does not disclose her sending frequencies () although the combination of her messages () might be learned, i.e. achieving . However, Alice might fear disclosing the combination of her messages - then she needs a protocol achieving at least , which hides the frequencies () and the message combination (), but discloses the sending histogram, i.e. how many people sent how many messages (). However, if multiple activist groups use the ACN actively at different time periods, disclosing the sending histogram might identify how many activist groups exist and to which events they respond by more active communication – to prevent this she needs a protocol that hides the frequencies and the histogram , i.e. provides .
Further, not only sending a certain content, but also being an active sender (i.e. being in ) is prosecuted she might want to pick a protocol with at least . Again if she is afraid that leaking or together with the expected external knowledge of the regime would lead to her identification, she picks the corresponding stronger notion. If the regime knows that senders in the ACN are activists and learns that the number of active senders is high, it blocks the ACN. In this case at least should be picked to hide the number of senders ().*
Example: * For the next protest, Alice sends two messages: (1) a location, and (2) a time. If the regime learns that both messages are from the same sender, they will block the place at this time even if they do not know who sent the messages.* Alice then needs a protocol that hides whether two communications have the same sender or not. We already explained how to model this with complex property in Section 4.2. The resulting notion is Twice Sender Unlinkability().
**Receiver Observability. ** In notions of this group the receiver of each communication can be learned. Hence, such notions include the property that the scenarios are equal except for the senders and messages () to ensure that they are equal in both scenarios.
Example: Consider not only sending real messages is persecuted, but also the message content or any combination of senders and message contents is exploited by the regime. If the regime e.g. can distinguish activist Alice sending “today” from regime supporter Charlie sending “see u”, it might have learned an information the activists would rather keep from the regime. Further, either (1) the activists know that many messages of a certain length are sent or (2) they are not sure that many messages of a certain length are sent.
In case (1), Alice needs a ACN, that hides the sender activity, the message content and their combination. However, the adversary can especially learn the message length. Modeling this, beyond the above described , the message lengths have to be equal . This results in the notion Sender Unobservability with Message Unobservability leaking Message Length (). Note that in the properties of are included and further the senders are allowed to differ in the two scenarios. The second case (2) requires a protocol that additionally hides the message length. Hence, in modeling it we remove the property that the message lengths are equal from the above notion. This results in Sender Unobservability with Message Unobservability ().
Example: * Alice’s demonstration is only at risk if the regime can link a message with a certain content to her as a sender with a non negligible probability.* Then at least Sender-Message Pair Unlinkability (), which is defined analogous to is needed.
Example (cont.): However, only allows Alice to claim that not she, but Charlie sent a critical message and the regime cannot know or guess better. Now assume that Dave is also communicating, then the regime might be able to distinguish Alice sending , Charlie and Dave from Alice sending , Charlie and Dave . In this case, it might not even matter that Alice can claim that Charlie possibly sent her message. The fact that when comparing all three communications that possibly happened, Alice is more likely to have sent the critical message means a risk for her.
To circumvent this problem Alice needs a protocol that not only hides the difference between single pairs of users, but any number of users. Modeling this, instead of the complex property , we need to restrict that the active senders’ sending frequencies are equal, i.e. .
Example: *In another situation our activists already are prosecuted for being a sender while a message with critical content is sent. *
In this case at least Sender-Message Pair Unobservability (), which is defined analogous to is needed.
Analogous notions are defined for receivers.
**Sender Privacy Notions: Both-Side Message Unlinkability. ** As explained with the example before in the case that Alice does not want any information about senders, receivers and messages or their combination to leak, she would use . However, the privacy in this example can be tuned down, if she assumes that the regime does not have certain external knowledge or that the users are accordingly careful. As explained for the Sender Notions with Receiver-Message Linkability before, in this case we might decide to allow to leak.
If a notion is extended to Sender Unobservability by X (), the leaking of the sender-message relation is removed. This is done by removing . Since the attacker now has a greater degree of freedom in choosing the senders and is (if at all) only restricted in how she chooses the receivers and messages, this is a special strong kind of Sender Unobservability. Analogous notions are defined for receivers.999Note that .
6.2 Analyzing Loopix’s Privacy Goals
To check if we include currently-used privacy goals, we decide on a current ACN that has defined its goals based on an existing analytical framework and which has already been analyzed: the Loopix anonymity system [15]. In this section, we show that the privacy goals of Loopix map to notions we have defined (although the naming differs). Loopix aims for Sender-Receiver Third-Party Unlinkability, Sender online Unobservability and Receiver Unobservability.
**Sender-Receiver Third-Party Unlinkability. ** Sender-Receiver Third-Party Unlinkability means that an adversary cannot distinguish scenarios where two receivers are switched:
“The senders and receivers should be unlinkable by any unauthorized party. Thus, we consider an adversary that wants to infer whether two users are communicating. We define sender-receiver third party unlinkability as the inability of the adversary to distinguish whether or for any concurrently online honest senders and honest receivers of the adversary’s choice.” [15]
The definition in Loopix allows the two scenarios to be distinguished by learning the first receiver. We interpret the notion such that it is only broken if the adversary learns a sender-receiver-pair, which we assume is what is meant in [15]. This means that the sender and receiver of a communication must be learned and is exactly the goal that motivated our introduction of complex properties: .
**Unobservability. ** In sender online unobservability the adversary cannot distinguish whether an adversary-chosen sender communicates () or not ():
“Whether or not senders are communicating should be hidden from an unauthorized third party. We define sender online unobservability as the inability of an adversary to decide whether a specific sender is communicating with any receiver or not , for any concurrently online honest sender of the adversary’s choice.” [15]
Receiver unobservability is defined analogously.
Those definitions are open to interpretation. On the one hand, can mean that there is no corresponding communication in the other scenario. This corresponds to our and the definition of and according to Table 4. When a sender is not sending in one of the two scenarios, this means that there will be a receiver receiving in the other, but not in this scenario. Hence, can be broken by learning about receivers and the two notions are equal. These notions are equivalent to :
Theorem 1**.**
It holds that
[TABLE]
[TABLE]
- Proof sketch.
by definition. For we use the following argumentation: Given an attack on , we can construct an attack on with the same success. Assume a protocol has , but not . Because it does not achieve , there exists a successful attack on . However, this implies that there exists a successful attack on (we even know how to construct it). This contradicts that the protocol has . We construct an successful attack on by creating two new batches and for every challenge row in the successful attack on . ∎
On the other hand, can mean that sender does not send anything in this challenge. In this case, the receivers can experience the same behavior in both scenarios and the notions differ. We formulate these notions as and according to Table 4. Therefore, we need a new property that some sender/receiver is not participating in any communication in the second scenario:
Definition 12** (Property ).**
Let be the sender of the first scenario in the first challenge row of this challenge. We say that is fulfilled iff for all . (Property is defined analogously for receivers.)
Theorem 2**.**
It holds that
[TABLE]
- Proof sketch.
Analogously to Theorem 1. : Every attack on is by definition a valid attack on .
: Given an attack on , where both scenarios of a challenge use all users (otherwise it would be a valid attack on ). Let be the same batch as the second of except that whenever one of the two senders of the first challenge row from the original scenarios is used, it is replaced with an arbitrary other sender (that was not used in the first challenge row of the original scenarios). Let be the probability that outputs 0, when the new batches are run; when the first scenario of is run and when the second is run. In the worst case for the attacker (otherwise we would replace the scenario where is minimal with the new one and get better parameters in the following calculation). Since is an attack on , . Transposing and inserting the worst case for leads to: . Hence, using with the adapted scenario is an attack on 101010An analogous argumentation works for .. ∎
This is equivalent to AnoA’s sender anonymity . Analogously, Loopix’s corresponding receiver notion is equivalent to , which is even weaker than AnoA’s receiver anonymity.
**Remark. ** We do not claim that the Loopix system achieves or does not achieve any of these notions, since we based our analysis on the definitions of their goals, which were not sufficient to unambiguously derive the corresponding notions.
7 Options for Notions
Additionally to the properties, we define options. Options can be added to any notion and allow for a more precise mapping of real world protocols, aspects of the adversary model, or easier analysis by quantification.
7.1 Protocol-dependent: Sessions
Some ACN protocols, like e.g. Tor, use sessions. Sessions encapsulate sequences of communications from the same sender to the same receiver by using the same session identifier for them. In reality, the adversary might be able to observe the session identifiers but (in most cases) not to link them to a specific user.
To model sessions, we therefore set the auxiliary information of a communication to the session ID (): . However, as the adversary can choose this auxiliary information, we need to ensure that the scenarios cannot be distinguished just because the session identifier is observed. Hence, we definine to be a number in most communications. Only for the session notions, we require special session IDs that correspond to the current challenge and stage in all challenge rows: . In this way, they have to be the same in both scenarios and a concrete is only used in one stage of one challenge.
The session identifier that is handed to the ACN protocol model is a random number that is generated by the challenger when a new is seen. Hence, neither leaking (it is a random number) nor linking session identifiers (it will be picked new and statistically independent for every challenge and stage) will give the attacker an advantage.
We formalize this in the following definition, where we also use ‘’ to declare that this part of a tuple can be any value.111111E.g. will be true iff .
Definition 13** (Sessions).**
Let be the stage and be the senders and receivers of the first challenge row of this challenge and stage in instance . Property is met, iff for all :
[TABLE]
As not all protocols use sessions, we allow to add sessions as an option to the notion abbreviated by .
7.2 Adversary Model: Corruption
Some adversary capabilities like user corruption imply additional checks our challenger has to do. As all properties are independent from corruption, we add corruption as an option, that can be more or less restricted as shown in Table 5. The different corruption options have implications on the challenger, when a corrupt query or a batch query arrives.
Check on corrupt queries. This check depends on whether the user corruption is adaptive, static, or not allowed at all. The default case for notion is adaptive corruption, i.e. the adversary can corrupt honest users at any time. With static corruption , the adversary has to corrupt a set of users before she sends her first batch. The third option, , is that no user corruption is allowed. We denote the set of corrupted users as .
Definition 14** (Corruption: Check on Corrupt Query).**
Let be the set of already corrupted users, the user in the corrupt query and the bit be true iff at least one batch query happened. The following properties are met, iff:
[TABLE]
Check on batch queries. In reality for most ACNs the privacy goal can be broken for corrupted users, e.g. a corrupted sender has no unobservability. Therefore, we need to assure that the adversary cannot distinguish the scenario because the behavior of corrupted users differs. This is done by assuring equal behavior or banning such users from communicating .
Definition 15** (Corruption: Check on Batch Query).**
The following properties are met, iff for all :
[TABLE]
Of course user corruption is not the only important part of an adversary model. Other adversarial capabilities can be adjusted with other parts of our framework (like the corruption of other parts of the ACN with protocol queries).
7.3 Easier Analysis: Quantification
For an easier analysis, we allow the quantification of notions in the options. This way a reduced number of challenge rows (challenge complexity) or of challenges (challenge cardinality) can be required. The next section includes information on how results with low challenge cardinality imply results for higher challenge cardinalities.
**Challenge Complexity. ** Example: Consider Alice using a protocol, that achieves for one challenge row (), but not for two (). This means in the case that Alice only communicates once, the adversary is not able to distinguish Alice from any other potential sender Charlie. However, if Alice communicates twice the regime might distinguish her existence from the existence of some other user, e.g. by using an intersection attack.
To quantify how different the scenarios can be, we add the concept of challenge complexity. Challenge complexity is measured in Challenge rows, the pairs of communications that differ in the two scenarios as defined earlier. is the maximal allowed number of challenge rows in the game. Additionally, we add the maximal allowed numbers of challenge rows per challenge as option to a notion with .
Definition 16** (Challenge Complexity).**
Let be the number of challenge rows in this challenge so far, We say that the following property is met, iff:
[TABLE]
**Challenges Cardinality. ** So far, our definitions focused on one challenge. We now bound the number of challenges to , as the adversary potentially gains more information the more challenges are played. While challenge complexity defines a bound on the total number of differing rows within a single challenge, cardinality bounds the total number of challenges. Communications belonging to a challenge are identified by the challenge number , which has to be between 1 and to be valid. The challenge number is a part of the auxiliary information of the communication and is only used by the challenger, not by the protocol model.
This dimension of quantification can be useful for analysis, since for certain assumptions the privacy of the -challenge-case can be bounded in the privacy of the single-challenge-case as we will discuss in the next section.
8 Capturing Different Adversaries
The adversary model assumed in the protocol model can be further restricted by adding adversary classes, that filter the information from the adversary to the challenger and vice versa. Potentially many such adversary classes can be defined.
Adversary Classes. AnoA introduces adversary classes, i.e. a PPT algorithm that can modify and filter all in- and outputs from/to the adversary. Adversary classes can be included into our framework in exactly the same way: to wrap the adversary . Instead of sending the queries to , sends the queries to , which can modify and filter them before sending them to . Similarly, the answers from are sent to and possibly modified and filtered before sent further to . Adversary classes that fulfill reliability, alpha-renaming and simulatability (see [3] for definitions) are called single-challenge reducible. For such adversary classes it holds that every protocol that is -X for , is also -X for . Even though our framework extends AnoA’s in multiple ways, the proof for multi-challenge generalization of AnoA is independent from those extensions and still applies to our framework.
- Proof sketch.
The proof is analogous to the one in Appendix A.1 of [3]121212Note, although they include the challenge number in the definition of achieving a notion, this is not used in the theorem.: we only argue that our added concepts (adaptive corruption, arbitrary sessions and grouping of challenge and input queries to batches) do not change the indistinguishability of the introduced games.
Adaptive Corruption In Games till , till and to communications that reach the protocol model are identical. Hence, also adaptive corruption queries between the batch queries will return the same results (if adaptive corruption is used probabilistic: the probability distribution for the results is equal in all these games). to and to by induction hypothesis. to and to adaptive corruption is independent from the used challenge numbers (called challenge tags in [3]).
The argumentation for sessions and batches in analogous. Notice that by using the batch concept, in some games a part of the communications of a batch might be simulated, while another part is not. ∎
Note that since the adversary class is only a PPT algorithm, still is a PPT algorithm and hence, a possible adversary against X when analyzed without an adversary class. So, while adversary classes can help to restrict the capabilities of the adversary, results shown in the case without an adversary class carry over.
Using UC-Realizability. AnoA shows that, if a protocol UC-realizes an ideal functionality , which achieves , also achieves ()-X for a negligible . As the proof is based on the - differential privacy definition of achieving a notion and independent from our extensions to the AnoA framework, this result still holds.
- Proof sketch.
AnoA’s proof assumes that does not achieve ()-X. Hence, there must be an attack distinguishing the scenarios. With this, they build a PPT distinguisher that uses to distinguish from . Since, even with our extensions still is a PPT algorithm, that can be used to build distinguisher and the inequalities that have to be true are the same (since the definition of achieving ()-X is the same as being -differentially private. The combination of not being ()-X and being results in the same contradiction as in AnoA’s proof. ∎
9 Relations to Prior Work
In this Section, we introduce existing frameworks and point out to which of our notions their notions corresponds.
We argue that our framework includes all their assumptions and notions relevant for ACNs and thus provides a combined basis for an analysis of ACNs. For each framework, we first quickly give an idea why the properties and options match the notions of it and focus on how the concepts (like batches) relate later on. The resulting mapping is shown in Table 7 and reasoned below.
AnoA Framework
AnoA [3] builds its privacy notions on differential privacy and compares them to their interpretation of the terminology paper of Pfitzmann and Hansen [14].
AnoA’s allows only one sender to change, the same is achieved with the combination of and . In AnoA’s also the messages can differ, but have to have the same length, which we account for with using and . AnoA’s will either end in one of the given sender-receiver combinations been chosen () or one of the mixed cases (). This is exact the same result as generates. For AnoA’s either the same sender is used in both stages or each of the senders is used in one of the stages. This behavior is achieved by our property . Although AnoA checks that the message length of the communication of both scenarios is equal, only the first message is used in any possible return result of . Hence, not checking the length and requiring the messages to be the same as we do in is neither weaker nor stronger.
Our model differs from AnoA’s model in the batch queries, the adaptive corruption, the arbitrary sessions and the use of notions instead of anonymity functions. Instead of batch queries AnoA distinguishes between input, i.e. communications that are equal for both scenarios, and challenge queries, i.e. challenge rows. Input queries are always valid in AnoA. They are also valid in our model, because all the privacy aspects used for our notions equivalent to AnoA’s hold true for identical batches without and is not allowed in the equivalent notions. In AnoA’s single-message anonymity functions only a limited number of challenge queries, i.e. challenge rows, is allowed per challenge. We ensure this restriction with . In AnoA, the adversary gets information after every communication. This is equivalent to multiple batches of size one in our case. We assume that for the analyzed protocol a protocol model can be created, which reveals the same or less information when it is invoked on a sequence of communications at once instead of being invoked for every single communication. Our notions, which match the AnoA notions, allow for batches of size one. So, our batch concept neither strengthens nor weakens the adversary.
AnoA’s corruption is static, does not protect corrupted users151515Although AnoA does not explicitly state this, we understand the analysis and notions of AnoA this way, as scenarios differing in the messages corrupted users send/receive could be trivially distinguished. and AnoA includes restrictions on sessions. Hence, AnoA’s notions translate to ours with the static corruption , the corrupted communication have to be equal in both scenarios and the session option of our model .
AnoA’s challenger does not only check properties, but modifies the batches with the anonymity functions. However, the modification results in one of at most four batches. We require those four batches (as combination of scenario and instances) as input from the adversary, because it is more intuitive that all possible scenarios stem from the adversary. This neither increases nor reduces the information the adversary learns, since she knows the challenger algorithm.
Bohli’s Framework
Bohli and Pashalidis [5] build a hierarchy of application-independent privacy notions based on what they define as “interesting properties”, that the adversary is or is not allowed to learn. Additionally, they compare their notions to Hevia’s, which we introduce next, and find equivalences.
It is easy to see, that our definitions of ( is not easy and hence, explained more detailed below) match the ones of Bohli’s properties (who sent, how often any sender sends and how many senders sent how often) although we do not use a function that links every output message with the sender(/receiver), but the sender-messages-sets(/receiver-messages-sets). Bohli and Pashalidis additionally define the restriction of picking their communications equal except for the user (depending on the current notion sender or receiver) . This is the same as allowing only the senders resp. receivers to differ ( resp. ).
Conceptually, our model differs from Bohli’s model in the concept of challenges, the advantage definition, the order of outputs, and the allowed behavior of corrupted users.
Bohli’s notions can be understood as one challenge () with arbitrarily many challenge rows (any ). Further, it does not use a multiplicative term in its advantage (). Then equals the advantage, which has to be 0 to unconditionally provide a privacy notion or negligible to computationally provide this notion.
Bohli’s framework assumes that the protocol outputs information as an information vector, where each entry belongs exactly to one communication. The adversary’s goal in Bohli’s framework is to link the index number of the output vector with the sender or receiver of the corresponding communication.
All except one of their properties can be determined given the batches of both scenarios. However, the linking relation property that partitions the index numbers of the output vector by user (sender or receiver depending on the notion), can only be calculated once the output order is known. Since our notions shall be independent from the analyzed protocol, the challenger cannot know the protocol and the way the output order is determined. Running the protocol on both scenarios might falsely result in differing output orders for non-deterministic protocols.
Thus, we adapt the linking relation for ACNs to be computable based on the batches. The interesting output elements the adversary tries to link in ACNs are messages. Hence, here the linking relation partitions the set of all messages into the sets of messages sent/received by the same user, which can be calculated based on the batches. This adaption is more restrictive for an adversary, since the partition of output numbers can be equal for both scenarios even though the sent messages are not. However, if the adversary is able to link the output number to the message, she can calculate our new linking relations based on Bohli’s.
Further, Bohli’s framework allows for notions, where the behavior of corrupted users differs in the two scenarios. This means privacy of corrupted users is provided, i.e. the adversary wins if she can observe the behavior of corrupted users. Those notions are the ones without the option .
To match our batch query, Bohli’s input queries, which include communications of both scenarios, have to be combined with a nextBatch query, which signals to hand all previous inputs to the protocol.
Hevia’s Framework
Hevia and Micciancio [13] define scenarios based on message matrices. Those message matrices specify who sends what message to whom. Notions restrict different communication properties like the number or set of sent/received messages per fixed user, or the number of total messages. Further, they construct a hierarchy of their notions and give optimal ACN protocol transformations that, when applied, lead from weaker to stronger notions.
Mapping of the properties follows mainly from Bohli’s and the equivalences between Bohli and Hevia (including the one we correct in the following paragraph). Besides this, only Hevia’s Unobservability (), where the matrices can be picked arbitrary, is new. However, this corresponds to our property, that always returns TRUE and allows any arbitrary scenarios.
Our model differs from Hevia’s, since ours considers the order of communications, allows adaptive attacks and corruption.
Our game allows to consider the order of communications. Analyzing protocol models that ignore the order will lead to identical results. However, protocol models that consider the order do not achieve a notion – although they would in Hevia’s framework, if an attack based on the order exists. 161616 Creating an adapted version left a degree of freedom. Our choice of adaptation corresponds with the interpretation of Hevia’s framework that was used, but not made explicit in Bohli’s framework.
Most of Hevia’s notions are already shown to match Bohli’s with only one batch () and no corruption () [5]. However, we have to correct two mappings: in [5] Hevia’s strong sender anonymity (), which requires the number of messages a receiver receives to be the same in both scenarios was mistakenly matched to Bohli’s sender weak unlinkability (), in which every sender sends the same number of messages in both scenarios. The needed restriction is realized in Bohli’s instead. The proof is analogous to Lemma 4.3 in [5]. The same reasoning leads to Bohli’s sender weak unlinkability () as the mapping for Hevia’s strong receiver anonymity ().
Gelernter’s Framework
Gelernter and Herzberg [11] extend Hevia’s framework to include corrupted participants. Additionally, they show that under this strong adversary an ACN protocol achieving the strongest notions exists. However, they prove that any ACN protocol with this strength has to be inefficient, i.e. the message overhead is at least linear in the number of honest senders. Further, they introduce relaxed privacy notions that can be efficiently achieved.
The notions of Gelernter’s framework build on Hevia’s and add corruption, which is covered in our corruption options. Only the relaxed notions and are not solely a corruption restriction. We define new notions as =\mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}$$\land G and = \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}$$\land Q\land G that are equivalent to some of the already introduced notions to make the mapping to the Gelernter’s notions obvious. They use a new property , in which scenarios are only allowed to differ in the sender names.
Definition 17** (Property ).**
Let be the set of all senders, s_{b_{i}}=\{(u,\{m_{1},\dots,m_{h}\})\bigm{|}u send message in batch the sender-messages sets for scenario . We say that is met, iff a permutation on exists such that for all .
Note that Gelernter’s relaxed notions (indistinguishability between permuted scenarios) is described by our property , the need for the existence of such a permutation.
Theorem 3**.**
It holds that
[TABLE]
- Proof sketch.
Analogous to Theorem 1.
: Every attack on is valid against : Since is fulfilled, for every sender in the first scenario, there exists a sender in the second scenario sending the same messages. Hence, the permutation between senders of the first and second scenario exists.
: Every attack on is valid against : Since there exists a permutation between the senders of the first and second scenario sending the same messages, the partitions of messages sent by the same sender are equal in both scenarios, i.e. is fulfilled.
is required in both notions by definition. Arguing that resp. is fulfilled given the other attack is analogous to .
∎
10 Hierarchy
Next, we want to compare all notions and establish their hierarchy. To do this, for any pair of notions we analyze which one is stronger than, i.e. implies, the other. This means, any ACN achieving the stronger notion also achieves the weaker (implied) one. Our result is shown in Figure 6, where all arrow types represent implications, and is proven as Theorem 4 below. Further, obvious implications between every notion , and exist, since only adds more possibilities to distinguish the scenarios. However, to avoid clutter we do not show them in Figure 6. To ease understanding the hierarchy for the first time, we added Appendix D where it is plotted together with the most important symbol tables. Further, the same hierarchy exists between notions with the same session, corruption and quantification options.
Further, we add a small hierarchy for the options that holds by definition in Figure 4.
Theorem 4**.**
The implications shown in Figure 6 hold.
- Proof.
Analogous to Theorem 1: We prove every implication by an indirect proof of the following outline: Given an attack on , we can construct an attack on with the same success. Assume a protocol has , but not . Because it does not achieve , there exists a successful attack on . However, this implies that there exists a successful attack on (we even know how to construct it). This contradicts that the protocol has .171717In AnoA, Bohli’s and Hevia’s framework some of these implications are proved for their notions in the same way. Due to this construction in the proof the implications are transitive.
We use different arrow styles in Figure 6 to partition the implications into those with analogous proofs.
The dashed, green implications hold, because of the following and analogous proofs:
Claim 1**.**
() If protocol achieves , it achieves .
- Proof.
Given a valid attack on . We show that is a valid attack on : Because of , is fulfilled. Because of , the receivers of the communications input to the protocol are the same in both scenarios. Hence, every receiver receives the same number of messages, i.e. is fulfilled. So, every attack against is valid against .
Now, assume a protocol that achieves , but not . Because it does not achieve , there has to exist an successful attack on , i.e.
[TABLE]
[TABLE]
We know is also valid against . Thus, it exists a attack, with
[TABLE]
[TABLE]
which contradicts the assumption that achieves . ∎
The dotted, yellow implications hold, because of the following and analogous proofs:
Claim 2**.**
() If protocol achieves , it achieves .
- Proof.
Given a valid attack on . We show that is a valid attack on : Because of of the receiver-message pairs of the communications input to the protocol are the same in both scenarios. Hence, every receiver receives the same messages, i.e. and are fulfilled. So, every attack against is valid against .
Now, the proof by contradiction is done analogous to the proof of Claim 1. ∎
All dark blue implications follow from the definition of the notions: Every valid attack against is valid against . This holds because , , , , , \mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}} and obviously for any properties and : resp. .
The dotted, red implications hold, because of the following and analogous proofs:
Claim 3**.**
() If protocol achieves , it achieves .
- Proof.
Given attack on . We show that is valid against : Sending nothing is not allowed in and hence, will not happen (\mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}) and because of , every sender sends equally often in both scenarios, i.e. Q is fulfilled.
Now, the proof by contradiction is done analogous to the proof of Claim 1. ∎
The cyan implications hold, because of the following and analogous proofs 181818For (resp. ) pick challenge rows differently; for and for to ensure that receivers (resp. messages) are equal.
For , (resp. , ) replace the challenge row with the corresponding two rows.:
Claim 4**.**
() If protocol achieves , it achieves .
- Proof.
We first argue the case of one challenge and later on extend it to multiple challenges. Given attack on . We construct two attacks and against and show that one of those has at least the desired success.
We construct attacks and . We therefore pick and . Those shall replace , which would be picked randomly by the challenger in to determine the batch instance. In we use the communications of corresponding to (for and ) as challenge row, whenever a batch in includes a challenge row. In we analogously use the communications corresponding to .
We show that both and are valid against : Sending nothing is also not allowed in and hence, will not happen (\mathrel{\ooalign{\hss\Diamond\hss\cr\kern-1.0pt\raise 0.0pt\hbox{\scalebox{1.0}{\not}}}}) and because of the fixed or , the senders of challenge rows are the same in both scenarios. Since also messages are equal in , the sender-message pairs are fixed (). Hence, and are valid against .
Since is an successful attack on and and against only fix the otherwise randomly picked :
[TABLE]
So,
[TABLE]
must hold true (otherwise we get a contradiction with the above inequality). Hence, or has to successfully break .
In case of multiple challenges: the instance bit is picked randomly for every challenge. Hence, we need to construct one attack for every possible combination of instance bit picks, i.e. attacks in total191919Note that this does not contradict the PPT requirement of our definition as only finding the right attack is theoretically exponential in the number of challenges allowed. However, the attack itself is still PPT (and might be even easier to find for a concrete protocol). from which each is a PPT algorithm and at least one is at least as successful as the attack on .
Now, the proof by contradiction is done analogous to the proof of Claim 1. ∎
**Remark. ** can be any value in the proofs (esp. or ) the proposed constructions apply changes for each challenge row.
Additionally, the corrupt queries are not changed by the proposed constructions. Hence, the implications hold true between those notions as long as they have the same corruption options. Analogously sessions are not modified by the constructions and the same implications hold true between notions with equal session options.
∎
Additional implications based on corruption and sessions are shown in Figure 4. Most of them hold by definition. Only the equivalence with and without challenge row restriction per challenge is not so easy to see and proven below.
Theorem 5**.**
For all :
. 2. 2.
, if number of challenges not restricted.
- Proof.
-
Trivial: Given an attack valid on restricted regarding the challenge rows per challenge. This attack is also valid against without challenge row restriction.
-
We need to construct a new attack:
Attack Construction 1**.**
Given an attack , we construct attack . Let be the number of previous challenges used in so far. For every batch query with challenge rows replace the challenge tag of the st st challenge row with ; continue with the next challenge rows and the increased challenge tag until no challenge rows are left. Use all other queries as does, give the answers to and output whatever outputs.
Given attack on . We construct an attack with the same success against by using Attack Construction 1. We show that is valid against : Attack Construction 1 assures, that at most challenge rows are used in every challenge (), all other aspects of are fullfilled in , too. Since perfectly simulates the given attack , it has the same success.
Now, the proof by contradiction is done analogous to the proof of Claim 1.
∎
So far we have proven that implications between notions exist. Further, we assure that the hierarchy is complete, i.e. that there exist no more implications between the notions of the hierarchy:
Theorem 6**.**
For all notions and of our hierarchy, where is not proven or implied by transitivity, there exists an ACN protocol achieving , but not .
- Proof.
**Overview. ** We construct the protocol in the following way: Given a protocol that achieves ( itself or a notion that implies ), let protocol run and additionally output some information . We argue that learning does not lead to any advantage distinguishing the scenarios for . Hence, achieves . We give an attack against where learning allows to distinguish the scenarios. Hence, does not achieve . Further, we use the knowledge that is transitive202020If and , it follows that . and give the systematic overview over all combinations from sender or impartial notions to all other notions and which proof applies for which relation in Table 8. Since receiver notions are completely analogous to sender notions, we spare this part of the table.
In Table 8 “” indicates that the notion of the column implies the one of the row. “” is used when the notions are equal. indicates that the counterexample is described in a proof with number . and are proofs covering multiple counterexamples and is a special one of those counterexamples. means the proof analogous to , but for the receiver notion. means that there cannot be an implication, because otherwise it would be a contradiction with proof since our implications are transitive.
**Numbered Proofs. ** The proofs identified in Table 8 follow.
Lemma 1**.**
. for any and any .
- Proof.
Given a protocol , that achieves . Let protocol be the protocol, that behaves like and additionally publishes the current number of receivers after every batch. Since in the number of receivers always needs to be identical in both scenarios, outputting it will not lead to new information for the adversary. So, achieves .
Fix arbitrarily. Let be valid receivers and a valid message. of can be broken by the following attack: An adversary inputs a batch query with two valid challenge rows with differing receivers212121For a simplified representation we only present the parts of the communication that differ in both scenarios and spare the senders of the communications.: as instance 0 of the first scenario, as instance 1 of the first scenario and as instance 0 and as instance 1 of the second scenario. If outputs the number of receivers as being 1, both messages have been received by the same user and outputs 0. Otherwise the number of receivers is 2 and the messages have been received by different users. It outputs 1 in this case and wins the game with certainty. Hence, \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(2R)\overline{L},c^{*},0)\rangle]=1 and \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(2R)\overline{L},c^{*},1)\rangle]=0 and thus \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(2R)\overline{L},c^{*},0)\rangle]>e^{\epsilon^{*}}\cdot\text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(2R)\overline{L},c^{*},1)\rangle]+\delta^{*} (since ).222222Notice, that any protocol would achieve for since no complete challenge is possible there. ∎
Tables 9 summarizes the ideas of proofs that work analogously to Lemma 1. means the sender(S)-message(m) pairs are published, i.e. it is leaked who sent which message. 1.(S,m) means that the first sender-message pair is revealed. |m| without brackets means the set of all message lengths is published; |U| the number of senders. The other abbreviations are used analogously. The attack is shortened to the format (communications of instance 0 scenario 0),(communications of instance 1 of scenario 0),(communications of instance 0 scenario 1),(communications of instance 1 of scenario 1) (if both instances of the scenario are equal, we shorten to:(communications of instance 0 scenario 0),(communications of instance 0 scenario 1) ) and all not mentioned elements are equal in both scenarios. are messages with , and ; senders and receivers.
Lemma 2**.**
. for any and for any .
- Proof.
Given a protocol with . Let behave like and additionally publish the first sender-receiver-pair. Since does not leak any information except how many messages are sent in total, does not leak any information except the first sender-receiver-pair and how many messages are sent in total. Hence, has , because who sends the second time is concealed (otherwise of could be broken based on this, which would be a contradiction to our assumption.).
Fix and let be valid senders and valid receivers. Then the following attack on is possible: The adversary creates a batch query containing only challenge rows: as instance 0 of the first scenario, as instance 1 of the first scenario and as instance 0 of the second scenario, as instance 1 of the second scenario. If the published first sender-receiver pair is or , outputs 0. Otherwise it outputs 1. Obviously, the adversary wins the game with certainty with this strategy. Hence, \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(SR)\overline{L},c^{*},0)\rangle]=1 and \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(SR)\overline{L},c^{*},1)\rangle]=0 and thus \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(SR)\overline{L},c^{*},0)\rangle]>e^{\epsilon^{*}}\cdot\text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},(SR)\overline{L},c^{*},1)\rangle]+\delta^{*} (since ) ∎
The proofs in Table 10 are done analogously to Lemma 2. This time, analogously proved relations are added in angle brackets.
Lemma 3**.**
. For , , , , , , , : If not in our hierarchy, for any and for any .
- Proof.
If not in our hierarchy, then in the adversary is more restricted, i.e. it exists a property , which has to be equal in both scenarios for , but neither has to be equal nor is implied to be equal for (See Figure 5 to see which property can be used for which choice of and ).
We now assume a protocol , that achieves . Let be the protocol that additionally publishes . still achieves , since in all attacks on not more information than in are given to the adversary (The adversary knows already since it is equal for both scenarios). However, since does not have to be equal in , the adversary can pick the scenarios such that it can distinguish them in based on with certainty. Hence for an arbitrary , \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},0)\rangle]=1 and \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},1)\rangle]=0 and thus \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},0)\rangle]>e^{\epsilon^{*}}\cdot\text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},1)\rangle]+\delta^{*} (since ). ∎
Lemma 4**.**
. For , , , , , , , , with : for any and for any .
- Proof.
If , then it exists a property , which has to be equal in both scenarios for , but neither has to equal nor is implied to be equal in (see Proof to Lemma 3 for details).
We now assume a protocol , that achieves . Let be the protocol that additionally outputs . Since the properties of are also checked in attacks for every valid attack on will result in the same version of for both scenarios. Hence, does not output new information to the adversary (compared to ) and still achieves .
However, since does not have to be equal in , the adversary can pick the scenario such that it can distinguish them with certainty in based on . Hence for an arbitrary , \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},0)\rangle]=1 and \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},1)\rangle]=0 and thus \text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},0)\rangle]>e^{\epsilon^{*}}\cdot\text{Pr}[0=\langle\mathcal{A}\bigm{|}Ch(\Pi^{\prime},X_{2},c^{*},1)\rangle]+\delta^{*} (since ). ∎
Lemma 5**.**
(Proofs , , ) ( analogous)
- Proof.
Protocol Construction 1**.**
Given a protocol that achieves and does not allow to recognize duplicated sender-message pairs, we construct protocol . Let run and additionally output a bit for every batch that contains only two communications. For some fixed senders and messages the protocol will additionally output a bit according to Table 11. For any other batch with two communications it will pick the output bit randomly.
Protocol outputs the challenge bit for and hence does not achieve . However, it achieves . The strategy of entering the same challenge row twice does not work because the advantage gained in the cases of (i.e. ) is annihilated in the cases of duplicated communications (i.e. ). Using one equal communication in both scenarios and a challenge row leads to another compensating distribution: The probability for a correct output is 0.25, for a wrong output 0.25 and for a random output 0.5. Another attack strategy is not possible since the additional output is only given for batches of size 2. ∎
**Remark. ** If a protocol does not achieve for , then it does not achieve for any (because every attack with only CR is also valid if more than CRs are allowed.) Further, notice that for some notions a minimum of two CRs is required (e.g. )
Additionally, for corruption options: since the proposed attacks do not use any corruption, they are valid for any corruption option. Analogously, since the proposed attacks do not use different sessions in both scenarios, they are valid for any session option.
∎
11 How to Use
The framework described above offers the opportunity to thoroughly analyze ACNs. To perform such an analysis, we advice a top-down approach as follows.
In case the ACN under analysis can be instantiated to protect against different adversaries, fix those parameters. 2. 2.
Extract capabilities of the adversary and general protocol properties from the ACN description: Specify the allowed user corruption. Is it none, static, adaptive? See Table 5. Are sessions (channels) constructed that link messages from the same sender? See Section 7.1. Extract all other capabilities to include them in the protocol model. 3. 3.
Simplify the ACN protocol in a protocol model: Generate a simplified protocol (ideal functionality) without cryptography by assuming secure communication. Show indistinguishability between this ideal functionality and the real-world protocol using a simulation based proof. Previous work [1] can guide the modeling step. See Section 9 (UC-realizability) for how the result of the simplified protocol can be transferred to the real-world protocol. 4. 4.
Extract properties based upon the input to the adversary from the ideal functionality: Start with simple properties, see Table 1. What does the adversary learn from the protocol execution? Continue with complex properties. See Section 4.2. 5. 5.
After mapping all properties from the protocol and adversary model to our framework, a privacy notions must be selected. Either the description of the ACN already specifies (in-)formally which privacy goal should be achieved, or the ACN under analysis should be shown to achieve a certain notion. See Table 6 for an overview of our defined notions. 6. 6.
As it is easier to show that a certain notion is not fulfilled compared to show that it is fulfilled, we propose to start with the strongest notions extracted this way. A notion is not fulfilled if the functionality (and thus the protocol) leaks a property to the adversary that he is not allowed to learn for the given notion. If it is not obvious that a notion is not fulfilled, check if the notion can be proven for the protocol model. The related work of Gelernter [11] and Backes [3] serve as examples for such proofs.
If the proof cannot be constructed or , a weaker notion can be selected for analysis. It might also help to consider the case of a limited number of challenge rows (see Section 7.3) and limit the adversary by using a single-challenge reducable adversary class (see Section 9 Adversary Class). In case the proof goes through and yields and a negligible , the protocol was shown to achieve the selected notion as per Definition 1. If or a non negligible , the protocol achieves the selected notion as per Definition 2.
If the protocol supports different adversaries, the steps described above can be repeated. This typically leads to adjusting the ideal functionality or adding different adversary classes (see Section 9) and thus fulfilling different properties of our framework. Analysis results under a variation of ACN parameters may achieve different notions in our hierarchy (Figure 6 and Figure 4). Based on our established relations between notions, analysis results can be compared for various parameters or parameter ranges, as well as against results of other ACNs.
12 Discussion
In this section, we present the lessons learned while creating our framework.
**Learning about privacy goals. ** The need for formal definitions is emphasized by the mapping of Loopix’s privacy goals to notions as example that less formal alternatives leave room for interpretation. Further, a result like our hierarchy would be much harder to achieve without formal definitions.
These definitions allow us to point out the relation of privacy and confidentiality (). The way we ordered the notions in the hierarchy allows easy identification the notions implying (the middle of the upper part). Note that any privacy notion implying can be broken by distinguishing the message’s content. Further, nearly all those notions also imply and hence, all such notions can be broken by learning the message length.
Our formal definitions also enabled the comparison of existing frameworks. Excluding differences in the adversarial model, quantifications and restrictions that do not apply to all ACNs, we observe that equivalent definitions are often defined independently by the authors of the analytical frameworks. For this reason, we included the notions of the other frameworks in our hierarchy in Figure 9 of Appendix 9. , , , and are defined (under different names) in multiple works; is even defined in all works.
Although previous work includes equivalent definitions, we realized that some notions are still missing. For example, we added weak notions like , and because they match our understanding of anonymity. Our understanding was confirmed by the analysis of Loopix’ goals. Further, we defined all analogous notions for all communication parties involved (senders and receivers) as real-world application define which party is more vulnerable. For the concrete applications we refer the reader to Section 6.1.
Consequently, we present a broad selection of privacy notions. We are aware that understanding them all in detail might be a challenging task, so we want to provide some intuitions and preferences, based on what we know and conjecture. We expect the lower part of the hierarchy to be more important for ACNs as [11] already includes an inefficiency result for and thus for all notions implying (see Figure 7 of the Appendix). As a first guess, we think , if higher overhead is manageable, , , (and receiver counterparts), and are the most popular notions for ACNs. Further, we want to add some results concerning two well-known systems to ease intuition. [3]’s analysis of Tor results in a small, but non-negligible probability to break and thus Tor does not achieve with our strict definition. Classical DC-Nets, on the other hand, do achieve at least [11]. We present our selection of notions also graphically in Figure 8 of the Appendix.
**Correcting Inconsistencies. ** While the above similarities most likely stem from the influence of prior informal work on privacy goals, attempts to provide concrete mappings have led to contradictions. The AnoA framework maps its notions to their interpretation of Pfitzmann and Hansen’s terminology. Pfitzmann and Hansen match their terminology to the notions of Hevia’s framework. This means that, notions of AnoA and Hevia’s framework are indirectly mapped. However, those notions are not equivalent. While AnoA’s sender anonymity and Hevia’s sender unlinkability are both mapped to Pfitzmann and Hansen’s sender anonymity, they differ: In Hevia’s sender unlinkability the number of times every sender sends can leak to the adversary, but in AnoA’s sender anonymity it cannot.
We belive that AnoA’s sender anonymity should be called sender unobservability, which is also our name for the corresponding notion. This follows the naming proposal of Pfitzmann and Hansen and their mapping to Hevia. It is also more suitable because AnoA’s sender anonymity can be broken by learning whether a certain sender is active, i.e. sends a real message, in the system (). In order to achieve this notion, all senders have to be unobservable. To verify this, we looked at how the notions of AnoA have been used. For example in [7] the protocol model contains an environment that lets all senders send randomly. Hence, is hidden by the use of this environment. We consider that the information that is allowed to be disclosed should instead be part of the notion and not modified by an environment. Only then are the notions able to represent what information is protected by the protocol.
Another lesson learned by comparing privacy notions is the power of names, because they introduce intuitions. The fact that Hevia’s strong sender anonymity is equivalent to Bohli’s receiver weak unlinkability seems counter-intuitive, since a sender notion is translated to a receiver notion. This might also be the reason for the incorrect mapping in [5]. However, Bohli’s receiver weak unlinkability is named this way because receivers are the “interesting” users, whose communication is restricted. It does not restrict senders in any way and hence should be, in most cases, easier to break according to some information about the sender. This is why we and Hevia have classified it as a sender notion. An analogous argument explains why Bohli’s receiver weak anonymity implies the restricted case of Bohli’s sender strong anonymity .
**Use and Limits. ** Because there is no restriction in the use of protocol queries, the only restriction to what can be analyzed is what is modeled in the protocol model. So, if the protocol model includes e.g. insider corruption and active behavior of the insider, like delaying or modifying of messages, those functionality can be used via protocol queries. The same applies to timing; if the protocol model specifies that it expects protocol queries telling it, that seconds passed and the adversary gets meaningful answers after this protocol messages and only an empty answer after batch queries (because they are only processed after some time passed), attacks on this can be analyzed. However, it needs to be specified in the protocol model. This model also defines the exact meaning of a batch query, whether messages of one batch are sent at the same time or in a sequence without interruption and specifies whether a synchronous or asynchronous communication model is used.
Defining the protocol model with the strongest adversary imaginable and restricting it later on with adversary classes is a way to limit the work, when analyzing against different adversary models. We decided not to increase the complexity of the framework further by adding interfaces for dimensions of adversary models to the protocol model, i.e. adding more dedicated query types instead of the versatile protocol query. So far, our decisions for query types are driven by the related work. Differentiating between the different possible use cases of protocol queries and defining a set of adversary classes defining typical adversaries based on this is future work. One of them should allow to limit the amount of corrupted users compared to the amount or honest users or specify n-1 attacks. Although we presented all notions that we deemed important, there might still be use cases that are not covered. With our properties as building blocks, we conjecture that it is easy to add the needed properties and use them in combination with ours. Further, for adding new notions to the hierarchy, our proofs can be used as templates.
Another possible extension is including and extending more results of the existing frameworks. Such results are Bohli’s closed hierarchy or Gelernter’s inefficiency result. Further, in Hevia’s framework techniques to achieve a stronger ACN are included. For instance, given an ACN achieving adding a certain cover traffic creates an ACN achieving . Those techniques hide certain information that is allowed to leak in the weaker but not in the stronger notion. The proof of our Theorem 6 already includes some information that is allowed to leak in the weaker but not in the stronger notion. Hence, it is a good starting point for finding more such techniques that help understanding and constructing ACNs better. We make the conjecture that adapting the proofs of all these results for our framework is possible. However, at the moment we leave proving of these results as future work.
13 Conclusion and Future Work
We have presented a framework of privacy notions for sharper analysis of ACNs that, to the best of our knowledge, includes more notions and assumptions than all existing frameworks based on indistinguishability games. To achieve this, we expressed privacy goals formally as privacy notions. We first presented their basic building blocks: properties. Those properties cover the observable information of communications, which is either required to remain private or allowed to be learned by an adversary, depending on the goal. Furthermore, we checked the sanity of the notions by finding exemplary use cases and by providing a mapping of the privacy goals of a current ACN to them. Our framework allows to compare and understand the differences in privacy goals. We proved the relations between our notions. This means that, for every pair of notions, we know which one is stronger than the other or if they are separate. This way, we resolved inconsistencies between the existing frameworks and built the basis to understand the strengths and weaknesses of ACNs better, which helps building improved ACNs. Further, it creates a unified basis for the analysis and comparison of ACNs.
**Future Work. ** Although our framework allows to analyze all types of attacks with the versatile protocol queries, the protocol model must support those attacks without systematic guidance by interfaces of the framework. Restrictions of such attacks thus cannot be expressed formally as part of the notion and hence are not easily represented. In future work we want to introduce more dedicated queries to also formalize other attack dimensions and based on this adversary classes for typical attackers. As we mentioned in the discussion, providing more intuitions and understanding the significance of notions is necessary. Therefore, analogous to the analysis of Loopix’s privacy goals, more current ACNs can be analyzed to understand which parts of the hierarchy they cover. This can also identify gaps in research; privacy goals for which ACNs are currently missing. Further, a survey of goals in greater depth would be useful to identify the most important notions in the hierarchy and to provide intuitions and thus ease deciding on the correct notions for practitioners.
Additionally, such a survey helps to understand the relationships between currently-employed privacy enhancing technologies. Finally, this understanding and the knowledge about how notions are related and differ can be used to define general techniques that strengthen ACNs.
Beyond that, an investigation of the applicability of our framework to other areas, like e.g. anonymous payment channels, would be interesting.
Acknowledgements
We would like to thank the anonymous reviewers for their helpful comments and feedback. Our work was partially funded by the German Research Foundation (DFG) within the Research Training Group GRK 1907, the German Federal Ministry of Education and Research (BMBF) within the EXPLOIDS project grant no. 16KIS0523 and European Union’s Horizon 2020 project SAINT grant no. 740829.
Appendix A Challenger
This section describes the queries to the challenger . Pseudocode of our challenger is shown in Algorithm 1 of Appendix A.
**Batch Query. ** The batches that the adversary chooses for the two scenarios are represented in batch queries. When the challenger receives a batch query, it will first check if their challenge number is valid, i.e. . Further, the challenger will validate the communications that would be input to for and as explained below. If the game is not aborted so far, the challenger will retrieve or create the current state of the challenge , which stores information to calculate the aspects. Afterwards it checks if the allowed total number of challenge rows is met. If all criteria are met so far, it checks that the aspects of the privacy notion are met by using the current state of the challenge , the set of corrupted users ,the instances for both scenarios . Finally, it runs the instance belonging to the challenge bit of this game and the for this challenge randomly chosen instance bit , if the aspects are matched. Otherwise, it returns and aborts the experiment. Running the scenario in the ACN protocol will return information that is forwarded to the adversary(or adversary class). This information is what an adversary is assumed to be able to observe.
**Corrupt Query. ** Corrupt queries represent adaptive, momentary corruption of users (senders or receivers). If the corrupt query is valid, the challenger forwards it to the ACN protocol. The ACN protocol returns the current state of the user to the challenger, who forwards it to the adversary. Active attacks based on corruption are realized with protocol queries if the protocol model allows for them.
**Protocol Query. ** Protocol queries allow the adversary e.g. to compromise parts of the network(not the users), set parameters of the ACN protocol or use other functionalities modeled in the protocol model, like e.g. active attacks. The meaning and validity of those queries is specific to the analyzed ACN protocol.
**Switch Stage Query. ** If this query occurs and it is allowed, i.e. the notion contains a relevant property, the stage is changed from 1 to 2.
**Validate Communications. ** If the analyzed ACN protocol specifies restrictions of senders and receiver-message pairs, their validity is checked by this function.
**Run Protocol. ** Run protocol first creates a new random session identifier if there is not already one for this session identifier of the adversary chosen session with the extension . This is done to ensure that the ACN protocol is not broken only because the session identifier is leaked. Afterwards it passes the communications to the ACN protocol formalization.
**Remark to simple properties and instances. ** In case the notion only uses simple properties, the challenger will pick and check the properties for and . In case the notion uses a combination of simple and complex properties, the challenger will check the simple properties for any pair and resulting by any .
Appendix B Notions in Pseudocode
CalcNewState always calculates the states for all user roles (senders and receivers). This is for improved readability. It would be sufficient to calculate the parts of the state needed for the current notion.
For the simple properties uses from resp. from to calculate and and compares them like in Definition 8. For the complex properties the senders and receivers of the first challenge row are stored in the -part and the current stage in the -part of s. With this complex properties are computed as stated in Definition 10. Further, for the sessions-aspect the -part of the state is set to if another sender-receiver-pair is used. With this and the and -information the Definition 13 can be checked. For the corruption it gets all the required information direct as input and can check it like defined in Definition 15. For the challenge complexity the number of challenge rows of this challenge is counted in the -part of the state and hence, Definition 16 can be calculated.
Appendix C Additional Tables and Lists
Appendix D Hierarchy And Tables
On the next page the hierarchy can be found combined with the symbol tables (Fig. 6 and Tables of 15). Further, Fig. 7 and Fig. 8 highlight special parts of the hierarchy and Fig. 9 presents the mapping of the notions of the other frameworks to ours.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1Backes et al. [2012] M. Backes, I. Goldberg, A. Kate, and E. Mohammadi. Provably Secure and Practical Onion Routing. In 2012 IEEE 25th Computer Security Foundations Symposium , 2012.
- 2Backes et al. [2014] M. Backes, A. Kate, P. Manoharan, S. Meiser, and E. Mohammadi. Anoa: A framework for analyzing anonymous communication protocols. 2014.
- 3Backes et al. [2017] M. Backes, A. Kate, P. Manoharan, S. Meiser, and E. Mohammadi. Ano A : A framework for analyzing anonymous communication protocols. Journal of Privacy and Confidentiality , 2017.
- 4Bellare et al. [1998] M. Bellare, A. Desai, D. Pointcheval, and P. Rogaway. Relations among notions of security for public-key encryption schemes. In Advances in Cryptology — CRYPTO ’98 . 1998.
- 5Bohli and Pashalidis [2011] J.-M. Bohli and A. Pashalidis. Relations among privacy notions. TISSEC , 2011.
- 6Chaum [1988] D. Chaum. The dining cryptographers problem: Unconditional sender and recipient untraceability. Journal of cryptology , 1988.
- 7Chaum et al. [2016] D. Chaum, F. Javani, A. Kate, A. Krasnova, J. de Ruiter, A. T. Sherman, and D. Das. c Mix : Anonymization by high-performance scalable mixing. USENIX Security , 2016.
- 8Chaum [1981] D. L. Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM , 1981.