owned this note
owned this note
Published
Linked with GitHub
# Group Formation for Asymmetric DC-nets - 2018
###### tags: `Tag(HashCloak - DC Net Readings)`
Authors: Simon Nicolas Helmut Becker
Paper: https://tuprints.ulb.tu-darmstadt.de/9143/7/thesis-final.pdf
### Table of Contents
[toc]
:::info
>Abstract: Many-to-many communication is a central component of widespread technologies like social networks and the IoT. For many applications, it is desirable that the anonymity of communication participants is preserved. We focus on the protection of sender anonymity in peer-to-peer networks that allow scalable group communication via publish-subscribe overlays.
>
>While DCnets can be used for achieving sender and receiver anonymity for many-to-many communication, they also induce a considerable communication and computation overhead. We address this challenge by introducing a modified version of DC-nets that induces less overhead than classical DC-nets while preserving their sender anonymity properties.
>
>Moreover, we present challenges that arise when combining publish-subscribe overlays with DC-nets. We introduce a novel technique that addresses the presented challenges, hereby protecting the anonymity of senders during its initialization and runtime. As our approach allows for anonymization groups of configurable size, we also analyze how groups that are suitable for this purpose can be formed.
:::
## 4 Theoretical Approach
### 4.1 Introduction
The challenge being addressed in this thesis is the protection of sender-anonymity in a layered P2P network with many-to-many communication.
### 4.2 Traditional Overlay Approach
With the traditional overlay approach, a peer that wants to send a message:
* Is either already part of an overlay.
* Joins an existing one.
* Or, initiates a new one.
As soon as it is part of the overlay, it can send messages to receivers on the overlay. This approach is highly problematic in terms of sender protection against our adversary model and leaves us with the following challenges:
1. $Sender$ $Identification$: An adversary can identify the sender of the message by determining where the message was first forwarded.
2. $Overlay$ $Interaction$ $Observation$: An adversary can observe who joined or initiated an overlay directly before a message was sent over this overlay. This peer is with high probability the sender of the message.
> Therefore, the traditional overlay approach grants no sender protection against our adversary model.
### 4.3 Overlays with DC-nets
The sender identification challenge introduced in Section 4.2 can be addressed by using DC-nets on top of overlays as shown in Figure 4.1.
![](https://i.imgur.com/8d7rMRc.png)
This way, overlay participants can use the DC-net for sending messages to receivers on this overlay. Hereby, eavesdropping adversaries cannot identify the sender of such messages.
However, new challenges arise:
3. $DC$-$net$ $Initialization Observation$: The DC-net has to be initiated by a peer.
* Hence, we encounter the same problems as for the overlay interaction observation challenge presented in Section 4.2.
4. $Overhead$: The enormous overhead of DC-nets has to be reduced before they can be practically used.
5. $Overlay$ $Churn$: DC-nets are not designed for dynamically joining and leaving participants.
* A DC-net has to be disbanded and newly created for every peer that joins or leaves the overlay on which the DC-net is running.
> Personal Note: Would participants be able to leave in an ETH2.0 validator setting?
6. $Anonymity$ $Set$ $Size $Limitation$: The anonymity set size of DC-nets is limited by the number of overlay participants. It may therefore be very small for less popular interests.
### 4.4 ADC-nets
We introduce a modified version of DC-nets that contain a rendezvous point (RP). A RP is a regular DC-net participant with additional tasks, namely:
1. Being the sole receiver of all DC-net messages of the DC-net.
2. Decrypting the published secret messages.
3. Forwarding them to their recipients that are not necessarily part of the DC-net.
> We refer to DC-nets that contain a RP as ADC-nets due to the asymmetric message flow between the RP and the other participants.
As published secret messages are sent to their recipients without protecting the anonymity of these recipients, receiver anonymity is not given for ADC-nets.
> Personal Note: This is acceptable since the pseudonyms would already be known as participants of an election in a PoS system?
#### 4.4.1 Rendezvous Point Election
In contrast to classical DC-nets, ADC-nets require the election of a RP before the actual communication can begin. Apart from this additional task, the initialization phase of ADC-nets is comparable to the one of DC-nets.
We formulate the following assumptions regarding the setting in which RP elections take place:
* Several peers have formed a group and initialize a new ADC-net for this group.
* Each of these peers knows every other peer in the group.
Prior to presenting the election scheme, we show the dangers of adversarial RPs. They can:
* $eavesdrop$ on published secret messages.
* $modify$ messages before forwarding them.
* $drop$ messages instead of forwarding them.
The presented challenges makes the election of a honest ADC-net participant as RP desirable.
* Hence, the RP election should be robust and prevent both colluding and non-colluding adversarial participants from gaining an unfair advantage.
* At the same time, it is desirable to take certain aspects, e.g., the location of ADC-net participants in the underlay, into account.
A non-distributed version of our approach is presented by Algorithm 1:
![](https://i.imgur.com/eBzlQfN.png)
![](https://i.imgur.com/KjuFDs7.png)
#### 4.4.2 Communication
In contrast to DC-nets, ADC-net messages are not broadcasted to all peers in the network.
* Instead, every participant only sends its ADC-net messages to the RP of the ADC-net.
* The RP then decrypts the messages published in the ADC-net and forwards them to their actual recipients.
* This reduces both the number of messages sent and the number of XOR operations executed per round.
* This addresses the overhead challenge.
#### 4.4.3 Transiency
We propose the following techniques for reducing the overhead induced by ADC-nets that are not sufficiently utilized:
* $Pausing$: ADC-nets can be paused by temporarily stopping the computation and sending of ADC-net messages. Paused ADC-nets can be resumed, for instance, after a previously defined timespan.
> Personal Note: Potentially allowing validators a choice to pause sending in case of set size decreasing due to other nodes being inactive? Form a new group of active nodes, form a new group of inactive nodes, when inactive nodes become active again, rearrange groups.
* $Disbanding$: ADC-nets can be disbanded by permanently stopping the computation and sending of ADC-net messages.
A number of challenges arise when using pausing and disbanding:
* $Low$ $Utilization$ $Detection$: A low ADC-net utilization has to be detected before pausing/disbanding can be initiated for the ADC-net.
* $Coordination$: ADC-net participants have to be informed of pausing/disbanding.
* $Transition$ $Phase$: Pausing/Disbanding should only commence after a reasonable transition period in which the ADC-net participants can prepare for it.
![](https://i.imgur.com/xMKQ0Km.png)
A variety of techniques for detecting a low ADC-net utilization are thinkable. We propose the following approach:
* The RP continuously measures the number of consecutive rounds in which only empty secrets messages were published.
* Hereby, it is predestined as coordinating entity and can initiate pausing/disbanding as soon as a certain threshold is exceeded.
* The transition period before an ADC-net is paused/disbanded should be long enough to allow its participants to finish publishing their last messages.
* Messages that were not successfully published during the transition phase are most likely delayed.
* They can only be sent after the paused ADC-net is resumed or using another ADC-net if the original ADC-net was disbanded.
### 4.5 Overlays with ADC-nets
> In this section, we introduce a new model that addresses the challenges introduced in the Sections 4.2 and 4.3. We use ADC-nets as intermediate layer between the underlay and multiple overlays instead of running DC-nets on specific overlays. An exemplary visualization of the model can be seen in Figure 4.2.
ADC-nets induce less overhead than DC-nets. Hence, the overhead challenge is addressed by using ADC-nets instead of classical DC-nets.
* We decouple ADC-net participants from overlay participants by using ADC-nets as intermediate layer between underlay and overlays.
* This decoupling addresses the overlay churn and the anonymity set size limitation challenges but at the same time introduces a new challenge:
7. $Group$ $Formation$: Suitable ADC-net groups have to be formed.
#### 4.5.1 ADC-net Initialization
By definition, the DC-net initialization observation challenge introduced in Section 4.3 also applies to ADC-nets.
* Before addressing this challenge, we introduce the concept of capacity due to its relevance for our approach:
* We assume that each peer can take part in multiple ADC-nets at the same time.
* However, the participation in each ADC-net results in both communicational and computational overhead for a peer.
* Especially if it is elected as RP.
* Therefore, peers can quickly be overloaded when the number of ADC-nets they can simultaneously take part in, is not limited.
* Each peer is able to configure a capacity that limits the number of ADC-nets it can simultaneously participate in.
We address the DC-net/ADC-net initialization observation challenge by using a randomized approach for the initialization of ADC-nets. It can be configured using the following parameters:
* $Capacity$: the capacity of the peer.
* $Interval$: the interval in which the initialization check is executed.
* $Probability$: the probability for initializing a new ADC-net.
The approach is presented by Algorithm 2 and is executed individually on each peer. We now explain each phase:
* $Continuous$ $Loop$: The peer periodically runs the initialization check.
* $Initialization$ $Check$: The peer checks whether it has the capacities to initialize a new ADC-net.
* If it has and if the probability check succeeds, the peer initiates a new ADC-net.
![](https://i.imgur.com/d9TMTW3.png)
With this approach, the initialization of ADC-nets is randomized and independent from whether a peer wants to send a message.
* For each message sent through the ADC-net:
* The probability of it being sent by the ADC-net initiator is equal to it being sent by another ADC-net participant.
* This solves the DC-net/ADC-net initialization observation challenge.
#### 4.5.2 Group Setup
It is required that each group participant knows every other group participant after the group setup phase.
* Only then can a RP be elected using the approach presented in Section 4.4.1.
![](https://i.imgur.com/lmxv10P.png)
To allow for a configurable anonymity set size, we introduce the following parameters that define a range of acceptable group sizes:
* $Group$ $Size$ $Minimum$: The minimum number of group participants required for a group setup to succeed.
* $Group$ $Size$ $Target$: the desired number of group participants.
The approach is presented by Algorithm 3. We now explain each phase:
* $Initialization$: The group setup is started by the peer acting as group setup initiator.
* $Forward$ $Request$: the group setup request is forwarded to another peer in a random walk-like manner.
* An unvisited neighbor of the current peer is selected as next peer.
* If no such neighbor exists, the group setup backtracks to the previous peer.
* If the group setup has already backtracked to the group setup initiator:
* It continues to the finish setup phase if the number of peers that have been recruited as participants equals or exceeds the group size minimum.
* Otherwise it goes to the cancel setup phase.
* $Handle$ $Request$: The group setup arrives at a new peer.
* If this peer is visited for the first time:
* It checks whether to take part in the group and does so if it has enough capacities left.
* Then, the group setup either continues to the finish setup or the forward request phase.
* Depending on whether the group size target has been reached.
* $Finish$ $Setup$: The group setup initiator notifies all peers that agreed to participate in the group.
* Those peers are now participants of the new group and know each other participant of the group.
* $Cancel$ $Setup$: The group setup initiator notifies all peers that agreed to participate in the group of its setup being canceled.
Each peer that decides to participate in a group setup reserves capacity for the case that it succeeds and results in a new ADC-nets.
* This reserved capacity is freed when the group setup is canceled.
* Hereby, it is ensured that the capacity is never exceeded.
![](https://i.imgur.com/h2IG0OS.png)
While our approach is easy to implement, it is problematic under the assumption of sabotaging insider adversaries. We encounter several problems that are similar to those presented in Section 2.6.3. Adversarial peers can:
* $impersonate$ other peers if they control all the communication links over which the random walk can reach these peers.
* Fake larger anonymity sets by pretending to be connected to peers that do not actually exist.
The impersonation challenge can be addressed by using unforgeable and verifiable signatures for all communication messages.
* This way, each peer can check for every message whether it was actually sent by the apparent sender and discard it if it was not.
Preventing adversaries from faking larger anonymity sets is more problematic.
Adversaries can easily disrupt group setups by refusing to forward random walks to other peers.
* To increase the probability of at least one random walk not being disrupted by an adversary, we propose the execution of multiple random walks in parallel.
* Individual adversaries that try to fake participants to control a large portion of the resulting group have to “take over” multiple group setups that are executed in a random walk-like manner to prevent other peers from increasing the effective anonymity set size of the resulting group.
The simultaneous execution of multiple random walks requires a modified version of Algorithm 3.
* We rely on a slightly modified version of the original algorithm with an additional timeout parameter.
* This parameter is used for stopping each random walk after a specific number of hops.
* It can prevent:
* The recruitment of too many participants.
* The traversal of all peers when only very few have capacities left.
Each random walk can be executed independently from the other random walks without coordination by the group initiator.
> We evaluate the performance of using multiple random walks and timeouts on the basis of this approach in Section 6.3. It can certainly be refined, for instance, by using periodic coordination of the random walks to reduce the number of peers that are visited/recruited by multiple random walks.
#### 4.5.3 Overlay Interaction
> We now address the overlay interaction observation challenge introduced in Section 4.2.
We propose that ADC-net participants conduct all sender-related overlay interactions through the ADC-net by using the RP as proxy.
* Adversaries can only observe sender-related overlay interactions of RPs but cannot identify the ADC-net participants behind these interactions.
* Sender-unrelated interactions can still be executed directly by peers.
* For instance, joining an overlay to receive messages on it,
* This solves the overlay interaction observation challenge.
Our specific approach relies on interest control messages that contain one topic of interest and can be used by ADC-net participants to anonymously notify the RP of their interests.
* These messages are published in ADC-nets as secret messages.
* When a RP receives an interest control message, it tries to join an existing overlay that addresses the topic of interest.
* If no such overlay exists, the RP initiates a new overlay for this topic.
* E.g., by using one of the techniques presented in Section 3.3.
* Using this approach, ADC-net participants can send their interests to the RP without being linked to them.
* This is crucial for sender protection as adversaries may use such information for identifying the sender of a message.
* Interests should only be sent one-by-one to prevent adversarial RPs from linking ADC-net participants to their interests by comparing interest sets across ADC-nets.
![](https://i.imgur.com/PESlXF6.png)
#### 4.5.4 Example
We present an example of our model in which we describe one of multiple scenarios that results in the network structure presented in Figure 4.2:
1. Peer 3 initializes the creation of the ADC-net after its initialization check, as presented in Section 4.5.1, succeeds.
2. Peer 3 starts the group setup as presented in Section 4.5.2. The outcome of this group setup is the set $G$ = $\{1, 2, 3, 4, 6\}$ containing the group participants.
3. The RP election is conducted as presented in Section 4.4.1 and with G as initial candidate set.
* Peer 4 is elected as RP.
4. The ADC-net participants generate master secrets as presented in Section 2.6.1.
5. The ADC-net participants can now induce the creation of the overlay by sending their interests to the RP as presented in Section 4.5.3. For simplicity, we assume that all peers in G are interested in the same topic and that the created overlay is related to this topic.
6. We assume that the remaining participants of the overlay joined it after its initialization by the RP.
7. Now, each participant of the ADC-net can use it to send messages to every participant of the overlay by using the RP as proxy as presented in Section 4.4.2.
## 5 Implementation
### 5.1 Introduction
We developed a prototypical framework for demonstrating and evaluating our theoretical approach.
* We chose Python as programming language for the implementation and elaborate on this selection in Section 5.2.
* Our framework comprises two main packages and several scripts:
* The $adc\_net$ package contains the main logic for running simulations and hence can be seen as the main application.
> The different components of this package are presented in Section 5.3.
* The main application is supplemented by several scripts that can be used for different purposes:
* Including the deployment of the framework.
* The execution of simulations with configuration presets.
* And the interaction with running simulations.
> The different scripts are presented in Section 5.4.
* The $adc\_net\_eval$ package contains the logic for evaluating simulation runs.
> Presented in Section 5.5.
### 5.2 Python
![](https://i.imgur.com/L6Btdom.png)
#### 5.2.2 Negative Aspects
CPython is the reference implementation of the Python interpreter and hence widely used.
* It uses a global interpreter lock (GIL) \[2\] which is a mutex that ensures that only one thread within a process can execute code at a time.
* While this ensures the thread-safety of certain Python operations, it prevents the effective use of multithreading.
* With our framework being designed for running local simulations with more than 1,000 peers of which each one runs multiple threads, the GIL becomes a critical problem.
* It is unfeasible to run simulations with this number of peers on only one CPU core.
Due to multithreading not being a viable alternative, we resort to multiprocessing where each peer has its own process.
* While running multiple Python threads is relatively lightweight due to many resources being shared among different threads, Python processes cause a higher memory usage due to the strict isolation of resources.
* We observed the impact of using multiprocessing instead of multithreading on the memory usage of our simulations and present our results in Table 5.1.
![](https://i.imgur.com/HNSRetz.png)
It can be seen that the memory usage increases significantly when using multiprocessing. However, we put up with the increased resource requirements as it allows us to fully utilize modern multi-core systems and conduct real-time simulations with a considerable number of peers.
#### 5.2.3 Community Packages
Our implementation depends on the following community packages:
* **cryptography**: cryptographic library package.
* Used for key exchanges and key derivation in the adc\_net/util/crypto wrapper module
* Presented in Section 5.3.4.
* **networkx**: network generation and interaction package.
* Used for the generation of network definitions in the network\_generation script
* Presented in Section 5.4.2.
* **paramiko**: SSH connection package.
* Used for remote deployment in the remote\_deploy script
* Presented in Section 5.4.1.
* **numpy**: array-processing package.
* Used for the evaluation in the adc\_net\_eval package
* Presented in Section 5.5.
* **scipy**: scientific library package.
* Used for the evaluation in the adc\_net\_eval package
* Presented in Section 5.5.
* **plotly**: plotting package.
* Used for the generation of evaluation plots in the adc\_net_eval package.
* Presented in Section 5.5.
### Main Application: $adc\_net$ Package
The $adc\_net$ package contains the functionality for running simulations and hence can be seen as our main application. We designed it with two main modes:
* **simulation**: All peers are simulated on one host using loopback addresses.
* **prototype**: Peers are simulated on multiple hosts in a local network.
#### 5.3.1 Program Entry: \_\_main\_\_.py
The \_\_main\_\_ module can be used for starting adc_net simulations. As such, it is responsible for:
* Loading the configuration from the file system using the conf
* Module presented in Section 5.3.2.
* Setting up debug logging using the logging module.
* Presented in Section 5.3.4.
* Setting up evaluation logging using the evaluation package
* Presented in Section 5.3.8 and
* Initializing one or multiple simulation peer(s) depending on the used main mode. Peers are initialized by instantiating the Peer class.
* presented in Section 5.3.6.
#### 5.3.2 Configuration: $conf.py$
The $conf$ module is used for reading configurations from the file system and for parsing them.
* We use the JSON format for configurations as it can easily be imported as python dictionary.
* We use the following types of configurations:
* $Main$: allows the configuration of most program settings.
* $Prototype$: allows the configuration of a single simulated peer.
* $Simulation$: allows the configuration of multiple simulated peers.
The prototype and simulation configurations mainly differ in the number of peers being configured.
* While the prototype configuration only contains one peer.
* The simulation configuration contains a list of peers.
#### 5.3.3 Network Communication: $comm.py$
The $comm$ module is used for low-level network communication between peers.
* We use UDP as communication protocol as it is connectionless and hence easy to use in a P2P setting.
* We use two designated threads:
1. $Sender$ $Thread$: Continuously fetches messages from the $send$ $queue$, serializes and sends them from the address of the current peer.
2. $Receiver$ $Thread$: Listens on the address of the current peer on the configured port, deserializes received messages and puts them into the $receive$ $queue$.
* This approach allows us to execute blocking network operations without blocking the peer logic.
* We propose the following thinkable improvements for real-world applications:
* $Multicast$: We only implement unicast communication.
* Multicast could be used for improving the performance of group communication operations.
* For instance, the distribution of RP election votes could be realized more efficiently using multicast.
* $Signatures$: As mentioned in Section 2.11, unforgeable and verifiable signatures could be used for preventing adversaries from impersonating other peers.
* This requires a public key infrastructure (PKI) which can be entrusted with the distribution of the public keys of each peer to allow the verification of signatures.
* Assuming the existence of such a PKI, the signing and verification of messages could be implemented on a low level in the $comm module as follows:
* Each outgoing messages is signed with the private key of the sending peer.
* The signature of each incoming message is verified using the public keys distributed by the PKI.
* If the verification fails, the message is discarded.
#### 5.3.4 Utilities: util Package
The $util$ package contains wrapper modules that encapsulate functionality from the Python standard library and community packages.
**Cryptography Wrapper: $crypto.py$**
The crypto module provides functions for cryptographic operations used throughout the adc_net module.
* We rely on the cryptography community package for the implementations of low-level cryptographic operations.
![](https://i.imgur.com/Zb1QsiJ.png)
The crypto module provides the following cryptographic functionality:
* The generation of asymmetric key pairs using ECC.
* The generation of shared master secrets for the ADC-net communication using pair-wise elliptic-curve Diffie-Hellman (ECDH) key exchanges.
* Both peers use their private key and the public key of the other peer for the ECDH key exchange.
* The derivation of round secrets using HKDF \[31\] as key derivation function (KDF).
* Round secrets for a specific master secret and a specific round are derived by using the master secret as input key material and the round number as salt.
While we keep our implementation simple, we propose the following thinkable improvements for real-world applications:
* Authenticated ECDH should be used to prevent man-in-the-middle (MITM) attacks.
* This can be achieved by using verifiable and unforgeable signatures for all communication messages as proposed in Section 5.3.3.
* As proposed in Section 2.6.3, new master secrets could be periodically generated to improve the security of the ADC-net communication.
**Logging Wrapper: $logging.py$**
The logging module functions as wrapper for the Python logging module and is used for debug logging.
5.3.5 Messaging: $messaging$ Package
* The messaging package is used for building and parsing standardized $program$ $messages$ that are used for the communication between different peers.
* Each program message contains a $type$ key whose value is an element of the $MsgType$ enumeration which contains all program message types.
* Therefore, each peer that receives a message can determine the type of this message and handle it accordingly as presented in Section 5.3.6.
#### 5.3.6 Peer Logic: $peer.py$
The peer module contains the Peer class. This class is used for simulating a peer and hereby combines the logic from the other adc_net modules.
As part of the initialization of a Peer instance, the following tasks are executed:
1. The interest set and the neighbor list of the peer are stored.
2. The communication component of the peer is initialized.
* The functionality of this component is presented in Section 5.3.3.
3. The approach logic handlers presented in Section 5.3.7 are initialized.
* They are used for the logic behind:
* Group setups.
* RP elections.
* And ADC-net functionality.
4. The following threads are initialized:
* $Message$ $Handler$ $Thread$: processes .received program messages.
* $Periodic$ $Handler$ $Thread$: executes certain tasks periodically.
> We use these two different threads as their tasks contain blocking operations, hence rendering a sequential implementation impractical. Both threads continuously execute their tasks until the peer receives a $shutdown$ program message and shuts down.
**Message Handler Logic**
The message handler continuously fetches received program messages from the receive queue presented in Section 5.3.3 and processes each of them as follows:
1. The type of the program message is parsed using the messaging package
* Presented in Section 5.3.5.
2. The other entries of the program message are parsed in dependency to its type using the $messaging$ package.
3. The handler function designated for this program message type is called with the parsed information.
Two special types of program messages are directly handled in the message handler of the peer:
* $Startup$: When a peer first receives a startup program message.
* It forwards this message to all its neighbors and then starts with the periodic execution of tasks.
* Subsequent startup program messages are ignored.
* $Shutdown$: When a peer receives a shutdown program message.
* It forwards this message to all its neighbors and then shuts down by terminating its handler threads.
![](https://i.imgur.com/fjoQ8xF.png)
**Periodic Handler Logic**
The periodic handler periodically executes tasks. We essentially have two types of tasks:
1. The (ADC-net) group setup initialization check presented in Section 5.3.7.
2. Periodic ADC-net tasks that are executed for all ADC-nets in which the peer participates.
* For instance, the periodic sending of ADC-net messages.
> As presented in the last section, the periodic handler only starts with the periodic execution of tasks after its peer has received a startup message. This addresses the startup phase message loss challenge.
#### 5.3.7 Approach Logic: handler Package
The main logic of our theoretical approach, which is presented in Chapter 4, is implemented in the handler package. in different modules.We implemented:
* Group setups.
* RP elections.
* And ADC-net functionality in different modules.
**Group Setup: $group.py$**
The $group$ handler module contains the logic for executing distributed group setups as presented by Algorithm 3.
* The communication for these setups is realized using a number of group setup program messages.
* It is desirable that multiple group setups can be executed in parallel in the same network without this potentially leading to identification problems.
* This requires a unique group identifier that can be used for linking each group setup program message to its respective group setup.
![](https://i.imgur.com/qoSeF4c.png)
![](https://i.imgur.com/sC8hCVC.png)
The module also includes the logic for periodically checking whether a new ADC-net should be initialized as such an initialization starts a new group setup.
* This check is implemented like the initialization check presented by Algorithm 2.
* It is periodically executed by the periodic handler of the peer as presented in Section 5.3.6.
**RP Election: $election.py$**
The election handler module contains the logic for executing distributed RP elections comparable to the non-distributed version presented by Algorithm 1.
* We refer to Section 4.4.1 for a detailed description of the used approach.
**ADC-net Functionality: $adc.py$**
The $adc$ handler module contains the logic for:
1. Finalizing the initialization of ADC-nets by generating master secrets.
2. And ADC-net runtime functionality.
For each ADC-net, master secrets are generated using ECC as presented in Section 5.3.4.
* Can be exchanged with any other technique that establishes master secrets as presented in 2.6.1.
Design decision made during the implementation:
* The theoretical approach presented in Section 4.4 does not specify when the decryption of ADC-net messages is conducted by RPs.
![](https://i.imgur.com/xU0Tg2p.png)
![](https://i.imgur.com/0wZFyNi.png)
* Approaches for collision detection and handling that can be applied to DC-nets can also be applied to ADC-nets.
* In Section 2.6.4, we presented the challenge of colliding non-empty secret messages.
* In Section 4.4.2, we presented an optional modification of the ADC-net communication model for allowing collision detection.
![](https://i.imgur.com/bMwbPtt.png)
* We wanted to be able to simulate the sender behavior of peers to allow more realistic simulations and a more detailed evaluation.
![](https://i.imgur.com/Bl2CSKX.png)
![](https://i.imgur.com/rifpEtU.png)
* In Section 4.4.3, we presented transient behavior as option for reducing the overhead induced by ADC-nets by disbanding ADC-nets that are not sufficiently utilized.
![](https://i.imgur.com/kIrPI2k.png)
* In Section 4.5, we presented how ADC-net participants can use the RP as proxy for overlay interactions.
![](https://i.imgur.com/sz16IJn.png)
#### 5.3.8 Evaluation: $evaluation$ Package
The $evaluation$ package contains functionality for logging information that is relevant for evaluation purposes. This is conducted as follows:
* We use evaluation messages for logging.
* Their format is comparable to the one used for program messages.
* Each peer logs its evaluation messages to a CSV log file designated for this peer.
* Hereby, the same evaluation logging logic can be used for local and distributed simulations.
* A peer logs an evaluation message when an evaluation-relevant event occurs.
* Each peer also creates a JSON metadata file containing the configuration options used for the simulation.
> As presented in Section 5.5, this information can be used for reconstructing and evaluating group setups, RP elections and ADC-nets.
### 5.4 Scripts
> We created a number of scripts for different tasks and present them in this section.
#### 5.4.1 Deployment: $deploy.py$, remote_deploy.py$
We wrote two scripts to allow the easy deployment of our framework:
* The $deploy$ script can be used for:
* Cloning the repository from a central Git repository.
* Pulling the latest version of the program code from this repository.
* Setting up a local Python virtual environment.
* Installing the required community packages in this virtual environment.
* The remote_deploy script can be used for
* Copying files required for the deployment to a remote host via SFTP and
* Executing the deploy script on a remote host via SSH.
The $deploy$ script relies on a private SSH key which only allows read access to the central Git repository and is stored in the repository itself.
* This way, the deploy script can execute Git operations using SSH without the need for additional SSH configuration on the host.
* While it is never a good idea to publish private keys in repositories, it is acceptable for this use case as only read access is granted.
The $remote_deploy$ script uses SSH for connecting to remote hosts.
* It was primarily designed for the deployment to Raspberry Pis located in a local network and therefore uses the Raspberry Pi default credentials for the SSH login.
#### 5.4.2 Network Generation: $network_generation.py$
The $network_generation$ script can be used for generating network definitions with configurable properties.
#### 5.4.3 Group Setup Simulation: $group\_setup\_simulation.py$
The $group\_setup\_simulation$ script can be used for simulating group setups with extended functionality without having to integrate the extensions into the group setup logic of our $adc\_net$ application.
* We created this script for conducting the evaluation presented in Section 6.3.
* For simplicity, we implemented a non-distributed version of the group setup algorithm presented in Section 4.5.2 which can be configured using the following group setup configuration options:
* $Number$ $of$ $Walks$: the number of random walks that are executed in parallel.
* $Group$ $Size$ Target: the desired number of group participants.
* $Participation$ $Probability$: the probability of a peer being recruited as participant when it is first visited by a random walk.
* This option functions as simple replacement of the capacity configuration and can be used for simulating the percentage of peers in a network that have reached their capacity.
* $Timeout$: the number of hops at which a random walk is finished regardless of the number of recruited participants.
A CLI can be used for supplying the group setups configuration options as arguments. Additionally, the following aspects can be configured via the CLI:
* The properties of the network used for the group setup simulations.
* The network is generated using the network generation script presented in Section 5.4.2.
* The number of simulations that are executed for the specified options.
* Whether the exhaustive simulation mode is enabled.
* It is used for the group setup evaluation presented in Section 6.3.
#### 5.4.4 Controlled ADC-net Execution: $batch\_execution, batch\_evaluation$
The $batch\_execution$ script can be used for executing $adc\_net$ simulations for a number of hard-coded configuration presets.
* It therefore functions as wrapper for the $adc\_net/\_\_main__$ module presented in Section 5.3.1.
* A number of configuration presets for the following configuration types exist:
* $RunMode$: defines whether local or distributed simulations are executed.
* $MainConfMode$: defines a number of modifications to the default $adc\_net$ main configuration.
* $NetworkConfMode$: defines the properties of the network used for the simulations.
* $network\_generation$ script presented in Section 5.4.2.
* $ControlMode$: defines interactions with a running simulation.
* In addition to hard-coded configuration presets,
* The number of simulations executed consecutively.
* The duration of each simulation in seconds.
* can be set.
![](https://i.imgur.com/PLwYLrp.png)
![](https://i.imgur.com/pr0XD3r.png)
The $batch\_evaluation$ script functions as wrapper for executing $adc\_net$ simulations for the evaluation for a number of configuration combinations. Its CLI can be used for selecting:
* Which type of evaluation simulation is run.
* And How many simulations are run for each configuration combination.
#### 5.4.5 Simulation Interaction
We created a number of scripts for interacting with running simulations and present them in this section.
**Simulation Startup: $startup.py$**
The $startup$ script can be used for sending a startup program message to a peer.
* This peer can be specified via a CLI by supplying an address and a port.
* Startup messages are presented in Section 5.3.6.
**Sender Control: $sender_control.py$**
The $sender\_control$ script can be used for sending sender control program messages to a peer to control its sender behavior.
* The different options that can be supplied to the script via a CLI are listed in Table A.6.
* When the script is executed, a sender control program message containing the specified configuration settings, except the addressing information, is sent to the addressed peer.
* How sender control program messages are handled by peers is described in Section 5.3.7.
**Simulation Shutdown: $shutdown.py$**
The $shutdown$ script can be used for sending a shutdown program message to a peer.
* This peer can be specified via a CLI by supplying an address and a port.
* Shutdown messages are presented in Section 5.3.6.
### 5.5 Evaluation Application: $adc\_net\_eval$ Package
The $adc\_net\_eval$ package can be used for evaluating group setups, RP elections, and ADC-nets simulated with the $adc\_net$ package presented in Section 5.3.
* The general evaluation procedure:
1. The adc_net evaluation logs for either a specified or all simulation runs are read in from the file system, parsed and used for reconstructing the group setups, RP elections and ADC-nets on-the-fly.
2. The reconstruction of the group setups, RP elections and ADC-nets is finalized.
3. The reconstructed information is used for evaluating a number of aspects.
4. (optional) Evaluation plots are created and exported to the file system.
5. (optional) The evaluation results are exported as JSON to the file system.
We use multiprocessing for the parallel evaluation of multiple simulation runs to fully utilize multi-core systems and reduce execution time.
## 6 Evaluation
### 6.1 Introduction
In this chapter, we evaluate our theoretical approach and our implementation of this approach. Furthermore, we discuss the results of this evaluation.
### 6.2 Comparison of DC-nets and ADC-nets
We presented classical DC-nets in Section 2.6 and introduced ADC-nets in Section 4.4.
* In Section 6.2.1, we compare them with regards to their anonymity set size.
* Then, in Section 6.2.2, we compare their communication and computation overhead.
#### 6.2.1 Anonymity Set Size
Larger anonymity sets do not necessarily exhibit a better privacy protection than smaller anonymity sets. However, we assume that larger anonymity sets always exhibit a better privacy protection to simplify the following comparison, which is visualized in Table 6.1:
* $Classical$ $DC$-$nets$ comprise all peers.
* Hence, they always exhibit the maximum anonymity set size that can be achieved in the underlying network.
* $ADC$-$nets$ comprise a configurable number of peers when used as presented in Section 4.5.
* Hence, the anonymity set size can be individually selected for specific use cases.
* For instance, communication with critical content can be protected by using larger anonymity sets at the cost of increased overhead.
![](https://i.imgur.com/DLtGXX2.png)
> Yet, it has to be noted that the anonymity set size of ADC-nets only applies for send operations. Due to our overhead reduction optimizations, receiver anonymity is not preserved anymore. However, this is not problematic for our approach as we only focus on sender protection.
#### 6.2.2 Overhead
We now compare the communication and computation overhead of classical DC-nets, ADC-nets and ADC-nets with collision detection.
* For both comparisons, we assume $p ≥ 2$ as number of DC-net/ADC-net participants.
* Furthermore, for ADC-nets, we assume $r$ as mean number of recipients per round to which a RP has to forward a published message.
**Communication Overhead**
Assume $m$ as number of messages which are sent over the network for each round of communication. We now compare $m$ for the different communication models and visualize the results in Table 6.2.
* $DC$-$nets$: Every participant has to send a $DC$-$net$ message to each other participant.
* $ADC$-$nets$: Every participant, except the RP, sends its ADC-net message to the RP.
* The RP does not send its ADC-net message to itself over the network but just stores is locally.
* After decrypting the published secret message, the RP sends it to its $r$ recipients.
* $ADC$-$nets$ with collision detection: In contrast to regular ADC-nets, the RP also sends the published message to each other ADC-net participant for collision handling purposes.
> Hereby, the amount of messages per round can be drastically reduced by using ADC-nets instead of DC-nets, especially for larger communication groups.
**Computation Overhead**
Assume $o$ as number of XOR operations which are executed for each round of communication. We now compare $o$ for the different communication models and visualize the results in Table 6.2.
* $DC$-$nets$: Every participant XORs its secret message with the round secrets it shares with each other participant.
* Furthermore, every participant XORs all received ADC-net messages of the round.
* $ADC$-$nets$: Every participant XORs its secret message with the round secrets it shares with each other participant.
* Only the RP XORs all received ADC-net messages of the round.
> Hereby, the amount of XOR operations per round can be reasonably reduced by using ADC-nets instead of DC-nets. While RPs execute the same amount of XOR operations as each participant in a DC-net, the other ADC-net peers are relieved of decrypting a message for each round.
### 6.3 Group Setups
#### 6.3.1 Approach
> The group setup approach presented in Section 4.5.2 is designed to be comparably simple and therefore easy to implement.
To allow the improvement of the approach in future work, we evaluate the impact of different group setup parameters on the following group setup properties:
* $Total$ $Path$ $Length$: the combined length of all random walks.
* $Visited$ $Peers$: the number of peers visited by all random walks.
* Peers that are visited by different random walks are counted:
* (total) multiple times.
* (unique) only once.
* Participants: the number of peers recruited by all random walks.
* Peers that are recruited by different random walks are counted
* (total) multiple times.
* (unique) only once.
![](https://i.imgur.com/sZVRqZx.png)
We desire a minimal total path length to only induce a minimal communication overhead while achieving a certain number of participants.
* Therefore, the difference between visited peers and participants should be minimal.
* Furthermore, when executing multiple random walks in parallel, it is desirable that every peer/participant is only visited/recruited by one random walk.
* To prevent unnecessary communication overhead.
#### 6.3.2 Experimental Setup
> We used the group\_setup\_simulation script, which is presented in Section 5.4.3, for the simulation of group setups with different configurations. We chose a number of settings for selected parameters of the group\_setup\_simulation script and list them in Table 6.3. These settings allow us to compare the impact of the parameters on the properties presented in Section 6.3.1.
> We used a network with 1,000 peers and a degree of 4 for the simulations. This network was generated using the network_generation script presented in Section 5.4.2. Furthermore, the initiator of each group setup was randomly selected from all peers. We ran 10,000 simulations for each combination of the parameter settings listed in Table 6.3, resulting in 144 different combinations and 1,440,000 simulations in total.
#### 6.3.3 Results
**Number of Walks**
In Section 4.5.2, we proposed the use of multiple random walks as potential disruption countermeasure and as way for reducing the power of individual adversaries that try to control a considerable portion of the resulting group. We now evaluate the impact of using different numbers of random walks in parallel by reference to Figure 6.1.
![](https://i.imgur.com/zNYCIbz.png)
As expected, the best results are achieved when using a single random walk.
* Here, it is known at all times which peers have been visited and recruited.
* Hence, visited peers are only re-visited when backtracking.
With an increasing number of random walks, the number of peers being visited by multiple random walks also increases, hereby adding additional communication overhead.
* This is a result of the different random walks not being coordinated.
* However, for a complete lack of coordination, the percentage of peers/participants that are only visited/recruited by a single random walk is relatively high.
* We expect that the performance can be further improved by periodically exchanging information regarding the visited and recruited peers between the different random walks.
> While using multiple random walks is more complex, the opportunities presented in Section 4.5.2 may outweigh the additional effort.
**Group Size Target**
Due to its impact on anonymity set size, group size is a central aspect of our group setup approach. We now evaluate the impact of using different group size target settings by reference to Figure 6.2.
![](https://i.imgur.com/zKDA4GW.png)
**Participation Probability**
For simplicity, we use the participation probability parameter instead of simulating the capacity for each peer in the network. We now evaluate the impact of using different participation probabilities by reference to Figure 6.3.
As expected, the participation probability has a direct effect on the ratio of visited peers to participants.
* The higher the participation probability, the more visited peers are also recruited as participants.
* This also explains the longer paths for lower participation probabilities as in average more peers have to be visited until the desired number of participants has been recruited.
![](https://i.imgur.com/pPzVVIc.png)
**Timeout**
As can clearly be seen, using no timeout drastically increases the total path length.
* This is especially critical in scenarios where only very few peers have capacities left.
* Then, a large portion of network is traversed.
* In the worst case, the whole network is traversed without reaching the group size target.
![](https://i.imgur.com/gX8j92K.png)
Our results indicate that timeouts should always be used.
### 6.4 Rendezvous Point Elections
#### 6.4.1 Approach
The RP election scheme presented in Section 4.4.1 is designed to randomly elect a leader from a set of candidates.
* We evaluate whether a number of elections in the same network results in a near-uniform distribution of leaders among all network peers.
* This is interesting in terms of load balancing.
* Additionally, we evaluate the speed of elections for different group sizes by comparing the following properties:
* $mean$ $drop$-$out$ $rate$: the mean percentage of candidates that are eliminated per election round. • number of rounds: the number of election rounds until a candidate is elected as RP.
> RPs should be elected as fast as possible to reduce the duration of ADC-net setups. Therefore, a high mean drop-out rate and a low number of rounds are desirable.
#### 6.4.2 Experimental Setup
We used the $batch\_evaluation$ script for running a number of comparable $adc\_net$ simulations for a selection of candidate $set$ $sizes$.
* Presented in Section 5.4.4.
![](https://i.imgur.com/tMeD9Dd.png)
#### 6.4.3 Results
**Election Speed**
Figure 6.5a clearly shows that the center of all mean drop-out rate distributions is located between 0.5 and 0.6.
* Hence, in average, more than half of the current candidates are eliminated per round.
* This behavior can also be observed in Figure 6.5b.
While elections with more candidates in general take longer than elections with less candidates, the number of additional rounds is quite small when compared to the number of additional candidates.
![](https://i.imgur.com/ipHRWOi.png)
**Leader Distribution**
![](https://i.imgur.com/uEey0fA.png)
Figure 6.6 shows the distribution of leaders in the network.
* It can clearly be observed that the leader distribution approximates the uniform distribution.
* This indicates that the election scheme presented in Section 4.4.1 indeed elects each ADC-net participant with equal probability as RP.
### 6.5 ADC-net Collision Handling
![](https://i.imgur.com/cSHjkxK.png)
#### 6.5.1 Approach
As presented in Section 5.3.7, we implemented a straightforward collision handling technique to allow the use of multiple senders per ADC-net. We evaluate the impact of different sender control modes, which are presented in Section 5.4.4, on the following aspects:
* The $percentage$ of $non$-$empty$ $messages$ that are published in the ADC-net.
* The $percentage$ of collisions for these $non$-$empty$ $messages$.
* The $mean$ $delay$ of $messages$ that are tracked using the sender_control message tracking functionality presented in Section 5.3.7.
#### 6.5.2 Experimental Setup
As in Section 6.4.2, we only modified few of the adc_net configuration options and relied on the default settings listed in the Tables A.1, A.2 and A.3 for the remaining options.
* We used a group setup initialization probability of 0.001.
* Hereby, on average, one of the 1,000 peers initiates a group setup for a new ADC-net per periodic interval.
* Due to the default group capacity and group size settings, exactly $1000\over{25}$ = 40 ADC-nets, each comprising 25 peers, are set up for every simulation.
#### 6.5.3 Results
**Percentage of Non-Empty Messages**
![](https://i.imgur.com/d6HOeaq.png)
As expected and observed in Figure 6.7a, the number of non-empty messages being published in ADC-nets increases with a higher sender rate and a higher send probability.
* Furthermore, it can be observed that non-empty secret messages are also published if the sender rate is zero.
* This is due to the use of interest control messages as presented in Section 4.5.3.
In Figure 6.7b, it is shown that higher wait probabilities result in fewer non-empty secret messages being published in ADC-nets.
* This is expectable as the average wait time of each peer that was part of a collision in an ADC-net is increased.
* Hereby, the number of non-empty secret messages it can publish in the same ADC-net is reduced.
**Percentage of Collisions for Non-Empty Messages**
![](https://i.imgur.com/bx7Fmww.png)
In Figure 6.8a, it can clearly be observed that an increase in sender rate and send probability increases the probability of published non-empty messages being part of a collision.
* Furthermore, the similarity of the results for the same sender rates and send probabilities of 0.2 and 0.5 should be noted.
* This indicates that a send probability of 0.2 is already too high as it results in the same number of collisions as the much higher setting of 0.5.
we can observe in Figure 6.8b that high wait probabilities result in a considerable reduction in the number of collisions when compared to smaller probabilities.
* Hence, while more messages can be published with a smaller wait probability.
* This is not necessarily positive as the majority of these messages is part of a collision and therefore has to be sent again.
**Mean Tracked Message Delay**
In the last section, we saw an increasing number of collisions for high sender rates and high send probabilities.
* This also has a direct impact on the message delay as can clearly be observed in Figure 6.9a.
* The same applies to our previous findings with regards to the number of collisions for different wait probabilities and is displayed in Figure 6.9b.
![](https://i.imgur.com/5dbBoHO.png)
Our results indicate that higher wait probabilities in general have a positive effect on the number of non-empty secret messages that are successfully published in ADC-nets.
### 6.6 ADC-net Transiency
#### 6.6.1 Approach
We presented transient behavior as a technique for reducing the continuous overhead induced by ADC-nets in Section 4.4.3.
* We now analyze the impact of different sender modes and threshold settings on the time until ADC-nets are disbanded.
* We measure this time by counting the number of ADC-net communication rounds in the respective ADC-net until the transiency transition was initiated and refer to it as transition start round.
#### 6.6.2 Experimental Setup
![](https://i.imgur.com/Pq5BXi3.png)
The experimental setup used for the ADC-net transiency simulations is very similar to the one presented in Section 6.5.2. Therefore, we only present the differences to the previously presented experimental setup:
* Transient ADC-net behavior was enabled.
* We used different ADC-net transiency transition thresholds instead of different ADC-net wait probabilities.
* We used the default ADC-net wait probability as listed in Table A.3.
#### Results
![](https://i.imgur.com/MiTniTp.png)
In Figure 6.11a, we can observe that the transition start round increases for higher sender rates and send probabilities.
* This was expected as our transiency approach disbands ADC-nets when only empty messages have been published for a number of consecutive rounds.
* It should be noted that the orange curve for the sender rate of 0.01 and the send probability of 0.05 is an outlier.
In Figure 6.11b, it can be observed that higher transition thresholds increase the mean transition start round as we expected.
* Furthermore, we see that most of the transitions happen comparably early.
* Yet, this may also be linked to the outlier problem mentioned before and has to be evaluated further by running simulations over a longer timespan.
### 6.7 Research Questions
When we started with the research associated with this thesis, we formulated a number of research questions which we wanted to address. We can now answer these questions and do so in the following sections.
#### 6.7.1 How to create the overlay without jeopardizing the identity of a sender?
In Section 4.5, we showed that RPs of ADC-nets can be used as proxies for overlay interactions.
* Using this approach, senders cannot be linked to overlay initializations as they never directly interact with overlays in their role as sender.
* Furthermore, we presented a technique for the randomized periodic initialization of ADC-nets in Section 4.5.1.
* This technique prevents that a sender intentionally, in its role as sender, initiates an ADC-net.
* This is important as otherwise, adversaries could identify the initiator of an ADC-net as initiator of an overlay that is initialized using the RP of the ADC-net as proxy.
#### 6.7.2 How long does it take until an overlay for a set of interests is set up?
The following tasks have to be carried out before an overlay can be set up:
1. $ADC$-$net$ $Initialization$: The ADC-net setup has to be randomly initiated by a peer,
* For instance, using the approach presented in Section 4.5.1.
2. $Group$ $Setup$: A number of participants for the new ADC-net have to be found.
* For instance, using the approach presented in Section 4.5.2.
3. $RP$ $Election$: A RP has to be elected for the ADC-net.
* For instance, using the approach presented in Section 4.4.1.
4. $ADC$-$net$ $Cryptography$ $Setup$: Pair-wise master secrets have to be agreed upon as presented in Section 2.6.1
For our presented techniques:
* The group setup phase most likely has the longest duration due to the distributed traversal of the network.
* The election phase instead is comparably short due to the fast speed of the used election scheme as showed in Section 6.4.
##### 6.7.3 Is it always possible to create ADC-net overlays with a previously set number of participants or is only a range of acceptable sizes practically feasible?
In Section 6.3, we showed that a previously set number of participants can be problematic to achieve, especially when only few peers have capacities left for taking part in a new ADC-net.
* Here, a range of acceptable group sizes should be used in combination with a group setup timeout.
* This prevents the traversal of large portions of the network which would induce a considerable communication overhead, especially for large networks.
When assuming a network in which most of the peers have enough capacities left for participating in a new ADC-net, a previously set number of participants is also feasible.
> Personal Note: How would you make this assumption?
#### 6.7.4 How does the anonymity set size of ADC-nets compare to that of DC-nets?
1. Classical DC-nets comprise all peers and hence exhibit the maximum anonymity set size that can be achieved in a network. ADC-nets in turn comprise a configurable number of peers, when used as presented in Section 4.5, and therefore exhibit configurable anonymity set sizes.
2. The anonymity set size of ADC-nets only applies to sender operations as they, in contrast to classical DC-nets, do not protect receiver anonymity. Therefore, they can only be used for sender protection.
#### 6.7.5 How does the communication overhead of ADC-nets compare to that of DC-nets?
ADC-nets induce significantly less communication overhead than classical DC-nets, especially for a high number of DC-net/ADC-net participants.
We summarize our results assuming $p ≥ 2$ as number of DC-net/ADC-net participants, $r$ as mean number of recipients per round to which a RP has to forward a published message and $m$ as the number of messages sent for each round of communication:
* $DC$-$nets$: Every participant has to send a DC-net message to each other participant.
* $m = p ·(p − 1)$
* $ADC$-$nets$: Every participant, except the RP, sends its ADC-net message to the RP. After decrypting the published secret message, the RP sends it to its $r$ recipients.
* $m = (p − 1) + r$
* $ADC$-$nets$ $with$ $collision$ $detection$: In contrast to regular ADC-nets, the RP also sends the published message to each other ADC-net participant for collision handling purposes.
* $m = 2 ·(p − 1) + r$
> Our results show that ADC-nets can be used as more efficient sender protection component than classical DC-nets. While ADC-nets with collision detection exhibit a higher communication overhead than ADC-nets without collision detection, they still perform much better than classical DC-nets
#### 6.7.6 How does the computational overhead of ADC-nets compare to that of DC-nets?
We summarize our results assuming $p ≥ 2$ as number of DC-net/ADC-net participants, and $o$ as the number of XOR operations executed for each round of communication:
* DC-nets: Every participant XORs its secret message with the round secrets it shares with each other participant. Furthermore, every participant XORs all received ADC-net messages of the round.
* $o = p ·(p − 1) + p ·(p − 1)$
* ADC-nets: Every participant XORs its secret message with the round secrets it shares with each other participant.
* Only the RP XORs all received ADC-net messages of the round.
* $o = p ·(p − 1) + p − 1$
> Each ADC-net participant, except the RP, only has to execute p − 1 XOR operations while the RP has to execute 2 ·(p − 1) XOR operations which is the same as each participant of a classical DC-net.
## 7 Conclusion
### 7.1 Motivation
While a number of feasible techniques exist for one-to-one communication, the ones that can be used for many-to-many communication induce a significant overhead and hence are not scalable. This is critical as many widespread technologies, e.g., social networks and the IoT, depend on many-to-many communication.
### 7.2 Contributions
We presented a number of challenges that are associated with sender protection in P2P networks when using pub-sub overlays for scalable many-to-many communication.
* We introduced ADC-nets as modified version of classical DC-nets with reduced overhead and maintained sender anonymity guarantees.
* We presented a novel approach that uses intermediate ADC-nets with configurable group sizes for sender protection.
* As part of this approach, we introduced a technique for forming suitable anonymization groups for a range of acceptable group sizes.
> Variable group sizes for the ADC-net would requite a large underlay membershop? (At least larger than each ADC-net group?)
### 7.3 Results
Our approach prevents the leakage of sender-related information during:
* The setup of ADC-nets for sender protection.
* Sender-related overlay interactions.
* And the sending of messages.
We also show that a timeout should always be used for group setups to prevent the traversal of large portions of the network and hereby a considerable communication overhead.
### 7.4 Future Work
We now present a number of aspects that could be addressed in future work:
* *Group Setup Coordination*: We showed that the use of multiple random walks may increase the disruption-resilience of group setups and also could restrict adversaries from controlling a large portion of the resulting group.
* However, we also showed that using multiple random walks can be problematic for larger groups when used without any coordination.
* We expect that the use of periodic coordination between multiple random walks can improve the performance of groups setups by preventing visiting/recruiting a peer multiple times.
* Therefore, it may be interesting to evaluate how periodic coordination can be realized and whether it has the expected effect.
* *ADC-net Pausing and Disbanding*: We presented pausing and disbanding of ADC-nets as option to further reduce overhead.
* It may be interesting to evaluate the impact of different pausing durations and disbanding thresholds on message delay and compare it to the achieved overhead reduction.
* The results could then indicate which pausing durations and disbanding thresholds are suitable for different use cases.
* *Disruption Resilience*: Disruption is a major problem that has to be addressed before our approach can be used in a real-world application.
* It may be interesting to think about ways to mitigate disruption by adversarial RPs, for instance, by periodically electing new RPs in ADC-nets.