# Evaluation of Circuit Lifetimes in Tor

Kevin Köster, Matthias Marx, Anne Kunstmann, Hannes Federrath

► To cite this version:

Kevin Köster, Matthias Marx, Anne Kunstmann, Hannes Federrath. Evaluation of Circuit Lifetimes in Tor. 37th IFIP International Conference on ICT Systems Security and Privacy Protection (SEC), Jun 2022, Copenhagen, Denmark. pp.142-157, 10.1007/978-3-031-06975-8_9. hal-05319915

HAL Id: hal-05319915

https://inria.hal.science/hal-05319915v1

Submitted on 17 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
Evaluation of Circuit Lifetimes in Tor

Kevin Köster(✉), Matthias Marx, Anne Kunstmann, and Hannes Federrath

Universität Hamburg, Hamburg, Germany
{kevin.koester, matthias.marx, anne.kunstmann, hannes.federrath}@uni-hamburg.de

**Abstract.** Tor is a popular anonymity network which achieves its anonymity by constructing paths over three Tor relays, so-called circuits. Multiple streams that correspond to TCP connections can be multiplexed over a single circuit. By default, circuits are used for about ten minutes before switching to new circuits. Once that time limit is reached the circuit cannot be used for any new streams. This time-window is called the maximum circuit dirtiness (MCD). This paper analyzes the consequences of changing the MCD for all clients in the network and provides data on how changing the MCD affects various metrics of the Tor network. Our analysis shows that reducing the MCD to a sane value has almost no impact on the clients. Neither performance nor anonymity of the clients are significantly affected by the MCD. On the relays however halving the default MCD reduces the memory usage by about 20% while maintaining the original throughput and no measurable increase in CPU usage. Raising the MCD shows the opposite effect and increases memory usage. By drastically reducing the MCD, a significant number of extra circuits are created. From a performance point of view, the MCD should be reduced. Building on this work, side effects on specific attacks on Tor should be investigated in future work.

**Keywords:** Tor · Circuit · Dirtiness · Privacy · Anonymity

# 1 Introduction

Tor [28] is a popular anonymity network with a large user base. It has about eight million daily [19] and about two million concurrent users [29]. The network itself consists of about 7 000 relays with a bandwidth of about 500 GiB/s [29]. It aims to provide low latency communication to enable Internet browsing and using real time applications such as voice chats. If a client wants to route data through the Tor network to a given target, it selects three relays and establishes an encrypted connection through them. This is called a *circuit* and the three chosen relays are known as the *guard*, the *middle* and the *exit*. For each hop the data is encrypted once and every relay decrypts one of the encryption layers. Finally the *exit* relay completely decrypts the data and sends it to the target. By using this method no relay ever knows the client and the target of a given connection at the same time. The target sees only the IP address of the *exit* relay, the IP address of the client
is concealed. Each circuit can handle multiple streams. When the client want to establish a connection to a target, Tor then tries to find a suitable existing *circuit* to use. If none is found a new *circuit* gets constructed. Since creating a new circuit involves establishing various connections and cryptographic handshakes which might induce a considerable delay, Tor prepares some open circuits in advance to keep the delay to a minimum.

When the age of a circuit exceeds a certain lifetime, no new streams can use this circuit and only already established streams are allowed to use it. The circuit is marked for closure as soon as all attached connections are closed. The circuit's lifetime is referred to as the maximum circuit dirtiness (MCD) and is, by default, 10 min. The MCD was last changed in 2005, where it was increased from 30 s to 10 min for performance reasons (commit d2400a5afd). In this paper, we evaluate different MCDs and their impact on performance and privacy.

The higher the MCD, the less frequently a client changes circuits. It might cause circuits to stay open even if they never see any user data again. With a lower MCD, those circuits would be closed earlier. A too low MCD, however, might result in an increased number of circuits which put additional strain on the Tor network. Furthermore, creating more circuits increases the number of opportunities to choose a malicious relay.

We use the *Shadow* discrete-event network simulator to run simulated Tor networks with different settings for the MCDs. Since the main motivation for changing the default MCDs in the first place was the relays' performance, we put a focus on evaluating the performance implications.

Our key findings are as follows:

1. Decreasing the default MCD on all Tor clients from 10 min to 5 min reduces memory usage of the relays by about 20%.

2. An MCD within a range of 30 s to 60 min has a small impact on the CPU usage of relays and no impact on the total throughput of the Tor network. By halving the default MCD to 5 min no measurable difference can be found.

3. Changing the MCD has a small influence on the total number of circuits created over time and the average amount of data transmitted per circuit. Reducing the MCD from 10 min to 5 min increases the number of circuits created by only about 3%.

The remainder of this paper is structured as follows: In Sect. 2, we present related work. In Sect. 3, we present our methodology and experimental setup, followed by Sect. 4 where we present our findings. Finally, we discuss unanswered questions and conclude our paper in Sect. 5.

## 2 Related Work

In this section, we present previous research related to Tor's MCD. First, we present prior work where the MCD was modified to control the creation of new circuits. Then, we describe approaches to formalize anonymity. Lastly, we provide a brief background on running realistic and reproducible simulations of the Tor network.
## 2.1 Modifying the Maximum Circuit Dirtiness

In the literature, the MCD has been modified to control creation of new circuits. However, to the best of our knowledge, it has not been studied how the MCD affects Tor's performance and users' privacy.

Wacek et al. [31] changed the MCD to increase the frequency at which new circuits are requested in order to study relay selection algorithms. The same approach was used by Wang and Goldberg [32], Kim et al. [16] and Shen et al. [26] who changed the MCD to enforce the usage of a new circuit for every visited website or conversely to prevent the generation of new circuits. The overall performance of the Tor network was not studied in these works.

Koch et al. [18] analyzed the reliability of circuits with respect to geographic locations of the exit nodes. They identified that circuits ending in Germany or the Netherlands usually are pretty stable and last the default MCD of ten minutes unless being closed before. Circuits ending in France, however, were quite unstable and had a higher number of timeouts. They observed an average circuit usage time of 7.5 min which is lower than the default MCD.

## 2.2 Assessing Anonymity, Privacy, and Security

By changing the MCD in Tor, we expect that the number of generated circuits increases which may influence the distribution of selected circuits. In order to show if changing the MCD affects the circuits Tor selects and thus might influence the anonymity of the clients, a metric is required. Furthermore an evaluation is needed if an adversary is able to gather more data due to a different MCD.

Serjantov et al. [24] and Díaz et al. [2,3] both independently proposed an anonymity metric based on the Shannon entropy [25]. The Shannon entropy can be calculated as follows

$$H(X) = -\sum_{i=1}^{n} p_i \log_2(p_i) \qquad (1)$$

where n is the number of total events and $p_i$ the probability of a specific event. The maximum entropy can be calculated with

$$H_{max} = \log_2(n) \qquad (2)$$

which is the case if $p_i = \frac{1}{n} \forall i \in 1, \dots, n$. To calculate a normalized entropy we just have to divide by the maximum entropy of the system

$$H_{norm}(X) = \frac{H(X)}{H_{max}} = -\sum_{i=1}^{n} p_i \log_n(p_i) \qquad (3)$$

In the context of Tor, n might be set to the number of possible entry-exit combinations and $p_i$ the probability a certain combination of relays is used to build a circuit. This can be used as a metric which shows the quality of circuit selection algorithms. The normalized entropy can then be used to compare systems with different amounts of users and selected circuit combinations.
In addition to measuring the entropy of the circuit selection, we take an adverse into account who controls part of the Tor network and aims to deanonymize the users. Tor is known to be susceptible to traffic correlation attacks [27]. Adversaries that are able to read a portion of incoming and outgoing traffic to and from the Tor network could link incoming traffic to outgoing traffic and thus deanonymize Tor users. To conduct such attacks, adversaries need control of some Tor guards and exits by either running them themselves or by hijacking existing relays. Alternatively, they could control an autonomous system (AS) or an Internet exchange point.

## 2.3 Simulation of Tor Networks

Since we cannot simply change the MCD (in a part) of the live Tor network, we evaluate different settings in a simulated Tor network. A variety of programs can be used for this. Moreover, simulating has the advantage that third parties can reproduce our results more easily.

Shadow [11] runs programs in an environment with a simulated network topology and time. Thus, the result of the simulation is not impacted by the speed of the simulating machine or other running tasks. This significantly improves the reproducibility of the simulations. Shadow is able to simulate an arbitrary amount of different hosts which is only limited by the available memory of the simulating host. The available processing power is also relevant as it speeds up the simulation but, with enough time, a slow CPU does not prevent the execution of a given simulation and leads to the same results as a fast CPU would do. As the simulation is a closed system, all encryption functions from Tor are disabled as they do not serve any purpose and only slow down the simulation. Since all calculations are done instantaneously for the simulated programs, this does not influence the results of the simulation but shows one major weakness of Shadow: Any CPU intensive calculation will not impact the network performance at all.

To measure the network performance some kind of traffic is needed. In prior experiments [5,8,17,19] a static recurring transfer with a size of 320 KiB was used to represent the download of a website. This approach dates back to 2010 and is based on the average size of a website [4]. However, this approach is outdated as the number of requests and data transmitted is far higher today. According to the HTTP Archive [7] the average size of a website in 2021 was about 2 MiB and consists of about 70 different requests. This clearly shows the need for newer and more accurate traffic models.

With Privcount, Jansen et al. [12] developed a program to measure Tor without compromising the anonymity of Tor users. They published a traffic model that is based on data captured in 2018 [14]. The model covers streams as well as packets based on real users behavior. To use that model in a simulation the application `tornettools` [10] is provided, which allows the generation of a realistic Tor network scaled to any size. To significantly reduce the run time of the simulation, 100 simulated clients use a common simulated Tor instance. This reduces the accuracy of the simulation, but also allows for a much larger simulation.
With *Chutney* [30] an alternative to *Shadow* exists which is able to simulate Tor networks. In contrast to *Shadow* it runs the networks in real-time and will not guarantee reproducibility as the environment does not provide a simulated time. Therefore the size of the simulated networks is heavily limited and we will use Chutney to confirm a part of our results.

# 3 Methodology

This section presents the simulation that was set up in order to evaluate different MCDs on the Tor network. Since the Tor specification does not precisely tell how to use every feature, e.g. repurposing existing circuits, Tor might behave unexpectedly at times. A purely theoretical evaluation approach is therefore not sufficient. Consequently, we simulate merely a fraction of the Tor network in order to modify the MCD and focus on its impact on the network performance.

The aforementioned *Shadow* simulator [11] combined with *tornettools* will be used to run the simulation and generate a realistic network along with realistic traffic. Since simulating the entire Tor network requires about 4 TiB of memory [13], we only simulate a fraction of the Tor network.

Additionally, we make use of *Shadow's* memory tracking functionality to determine the resource consumption of each simulated node. Since its memory tracking is not well-tested, we verify our results by adding the same functionality provided by *Chutney* [30]. Realistic client traffic is simulated with the help of *tgen* [23] and added to *Chutney* with the priorly mentioned traffic model. To track the memory consumption, we used *Hoptrack* [6] by integrating it into *Chutney*. *Hoptrack* provides insight into memory usage while inducing little CPU and memory overhead.

## 3.1 Adversary Model

To evaluate how changing MCD affects the client's security, we consider an adversary who is able to control a fraction of the Tor network. Following previous works [1,8], our adversary controls 10% of Tor's entry and exit bandwidth. Should a client choose a compromised entry and exit relay for a circuit, the circuit is considered compromised. The adversary is able to observe the traffic along that circuit and deanonymize the user. To simulate this adversary, relays were chosen randomly and added to the set of compromised nodes until the threshold of 10% for entry and exit bandwidth was reached. We kept track of the amount of traffic sent over those compromised relays and repeated the procedure ten times in order to calculate an average over the obtained results.

## 3.2 Simulation Parameters

Our hardware operates with 350 GiB of memory and is able to simulate a fraction of approximately 8% of the entire Tor network for one hour with unmodified Tor software. A modification of the MCD might cause the memory usage to
increase and subsequently decrease the largest possible network size that can be simulated. Due to this increase of memory usage, we first simulated a network fraction of 3% which allowed us to test a wider set of MCDs. We chose values ranging from 30 s, 50 s, 100 s, 200 s, 5 min, 400 s, 500 s, 10 min (default) to longer time periods of 20 min, 40 min, and 60 min.

During the evaluation of aforementioned MCDs, the value of 5 min stood out positively with regard to decreasing memory usage. A larger network fraction of 8% was simulated in order to evaluate the network's behavior with an MCD of 5 min at larger scale. For the simulation, four different snapshots of the Tor network from different months displayed in Table 1 were used three times and provided with an initial seed to avoid outliers and biases in our data. We only use one single traffic model and, thus, the number of clients does not change with the date and is fixed at 63 355 users for every simulation.

<table><caption>**Table 1.** Time windows used for Tor snapshots and their simulated network size scaled to 8% of the Tor network</caption><thead><tr><td>Month</td><td>Relays</td><td>Guards</td><td>Exits</td></tr></thead><tbody><tr><td>2021-01</td><td>553</td><td>263</td><td>123</td></tr><tr><td>2021-02</td><td>538</td><td>261</td><td>112</td></tr><tr><td>2021-03</td><td>537</td><td>271</td><td>102</td></tr><tr><td>2021-04</td><td>528</td><td>272</td><td>91</td></tr></tbody></table>

To generate the required files, we first select the respective snapshot of the Tor network. Then, we set the seed to “1” and increase it by 1 for every repeated simulation for a specific snapshot. The resulting configuration files are then copied, so even the used cryptographic keys are identical to the reference version. In these copies only the Setting “MaxCircuitDirtiness” is changed for all clients. The circuit renewal process was not modified and follows the Tor protocol.

## 3.3 Changes to the Simulation Software

To evaluate the simulation, several changes were made to the existing software stack. None of these changes should affect the result of the simulation and only provide additional data.

To quantify the CPU time of each host, we added an additional field to the *Shadow* heartbeat message which keeps track of the required CPU time. This CPU time period is quantified by measuring the time period between a timer before handing over the control to the process next in line. The timer is stopped after the process returns. Every interruption of the current process, e.g. writing to a socket or accessing the disk, is omitted from the measuring process by handing the control back to *Shadow* and in order to avoid skewing the obtained results. In this way, the actual CPU time only includes a small overhead for
<table><caption>**Table 2.** Used software versions</caption><thead><tr><td>Name</td><td>Commit</td><td>Based on version</td></tr></thead><tbody><tr><td>Tor</td><td>tor-0.3.5.7</td><td>0.3.5.7</td></tr><tr><td>Tornettools [10]</td><td>fd2f8d1</td><td>1.10</td></tr><tr><td>Oniontrace [22]</td><td>e9a9dd3</td><td>1.0.0</td></tr><tr><td>Shadow [9]</td><td>67c1f19f</td><td>1.15.0</td></tr><tr><td>Tgen [23]</td><td>47d5eb3</td><td>1.0.0</td></tr></tbody></table>

handing back the control as well as the timer start and stop. *Shadow* itself does not simulate the required CPU time and a high CPU usage does not impact the performance of the simulated program. We can only measure whether Tor uses more CPU but we cannot measure the impact the CPU usage has on other metrics.

By default, *Shadow* merely monitors the memory usage of the entire simulation. By enabling the “ram” option, this functionality can be extended to single hosts participating in the network. As *Shadow* catches every call for memory allocation and deallocation, it is possible to monitor all used memory on the heap for each simulated process. The impact of the stack on the total memory consumption on Linux systems is by default limited to 8 MiB [21] and thus negligible. No further changes were made to *Shadow*.

**Circuit Statistics** To evaluate how different MCDs affect the circuit generation, we expanded the plot scripts to include the number of active circuits for a given time. Additionally we observed all circuits generated by all clients to calculate the entropy of the circuit-selection. Since we are modifying the closing time of circuits it is reasonable to believe that we create more circuits which may impact the circuit selection algorithm. Therefore we calculate the Shannon entropy [25] as described in Sect. 2. As the *n* we are using all possible combinations of entry- and exit-nodes a client could choose. *p*<sub>*i*</sub>, *i* ∈ 1, .., *n* is the number of times the combination *i* was used by the clients divided by *n*. This metric shows the uniformity of the selection of entry and exit nodes. The middle nodes are not considered.

## 3.4 Reproducing Our Results

To make our results reproducible, all used software versions are provided in Table 2. The simulation with *tornettools* requires a bunch of preparation steps in order to simulate the Tor network. This includes, e.g., downloading the server descriptors as well as the consensus, *onionperf*, and bandwidth data for a specific time range. To facilitate the reproducibility of our evaluation, we provide an automation for these manual steps.<fnref n="1" />

<footnote n="1">¹ Available at https://github.com/kevinkoester/tornettools_manager.</footnote>
## 3.5 Limitations

Even though we are able to simulate many different states of the Tor network and use different seeds for the traffic generation, we are still limited to the single traffic model. The traffic model only generates active circuits which the clients actually use to send data, inactive circuits are not covered by the model.

As already mentioned, each calculation done in the simulation is done instantaneously from the perspective of the simulated program. Therefore an overload of the relays cannot be simulated using the default settings. *Shadow* offers the functionality to simulate those, but loses its determinism by doing that. Therefore we are able to measure the used CPU time while missing reproducibility of our measures.

# 4 Analysis

As described in Sect. 3, each simulation of the Tor network was set up based on the entirety of monthly Tor consensus documents and then provided with a seed. These simulations were then used to demonstrate how changing the MCD impacts the network performance. Among each simulation set, the results did not show any significant differences. For that reason, we selected one simulation from each set to represent the overall results. For simulations modeling a 3% fraction of the network size, we selected the Tor snapshot of May 2021. The larger simulations of 8% are built after the snapshot of March 2021. Both simulations use a seed of "1" as described in Sect. 4.

In the following subsections, the simulation results will be analyzed and the effects of raising and lowering the MCD will be discussed for each metric along with their impact on the Tor network. From our range of tested MCDs, we select two opposite values, 30 s (the previous default) and 60 min, to demonstrate the influence of extremes on both ends. Afterwards, we demonstrate how doubling and reducing the default MCD by half affects the network. Additionally, we show how the Tor network is affected by an MCD of 5 min with simulations that model a network fraction of 8%.

We first address the performance aspects in Subsect. 4.1 and eventually discuss some privacy implications in Subsect. 4.2.

## 4.1 Performance

The simulations show that decreasing the MCD reduces the Tor relays' memory usage while the clients stay mostly unaffected by this modification.

The simulations also show a slight trend towards lower CPU usage. However, those differences are within the margin of error and can show the opposite effect in other simulations. Thus, these results are not conclusive. Moreover, we could not observe any significant change in throughput or overhead in the network traffic for all tested MCDs.
**Circuit Generation.** Figure 1 shows the number of concurrently open circuits and the total number of created circuits for different numbers of MCDs on the Y-axis. The X-axis shows the simulated time.

In Fig. 1a, it can be seen that the number of concurrently open circuits stabilizes after a while. An exception is a MCD of 60 min which effectively disables the MCD functionality and thus circuits are never being closed due to their lifetime. This causes the number of concurrently open circuits and total created circuits to be almost identical.

Doubling the MCD from 10 min to 20 min increases the number of concurrently open circuits by about 73%. The difference between the default MCD of 10 min and 5 min is about 40%. The difference between 5 min and 30 s is relatively small at about 3%.

<figure><img src="image_3.png" /><figcaption>**Fig. 1.** Number of open circuits for different numbers of the MCD</figcaption></figure>

Lowering the MCD causes unused circuits to be closed sooner and thus we see a lower number of concurrently open circuits. Increasing the MCD causes the circuits to stay open longer even if they are never used again and thus results in an increased number of concurrently open circuits. One can also see that doubling the default MCD has a larger impact on the absolute number of concurrently open circuits than halving it. Reducing the MCD beyond 5 min only has diminishing returns. Overall the number of concurrently open circuits correlates with the MCD. The lower the MCD, the lower the number of concurrently open circuits.

Figure 1b shows that the higher the MCD is set, the lower the total amount of created circuits is. With a MCD of 30 s the total number of created circuits is increased by about 50% compared to the default MCD. Halving the MCD results in about 3% more circuits and doubling it in about 8% less circuits created.

With a lower MCD, circuits are closed sooner. Therefore the Tor client might need to create extra circuits for some streams if no suitable circuits are available, whereas with a higher MCD an already existing circuit could have been used.
If we run the same simulation with a larger network, we see similar results. Vanilla Tor creates about 142 600 concurrently open circuits as seen in Fig. 2a. Lowering the MCD to half of the original value causes the number of concurrently active circuits to be reduced to about 88 000, which is a reduction of about 38%. For the total number of created circuits we do see a difference, but it is rather small with a 3% increase.

Overall lowering the MCD leads to a decrease of concurrently open circuits while slightly increasing the total number of created circuits. Raising the MCD shows the opposite effect. The scale of the simulation doesn't influence this result.

<figure><img src="image_4.png" /><figcaption>Fig. 2. Number of open circuits with half the MCD</figcaption></figure>

**CPU Usage.** We note that the used CPU time is the only value that significantly changed throughout the experiments. In our smaller simulation (scaled to 3% of the Tor network), we observed a measurable difference for MCDs of 30 s and 60 min for a single configuration. This leads to an increase of about 10% for 30 s and a decrease of about 4.5% for an MCD of 60 min for the used CPU time. However, this is only the case for this specific configuration and other simulations didn't show this behavior. All other measurements were within the margin of error and showed a slightly lower, yet not conclusive, CPU usage for an MCD of 30 s. In the simulations scaled to 8% the size of the live Tor network, halving the MCD shows no significant difference throughout the simulation.

Overall, we see that measuring the CPU time in *Shadow* is not very reliable. But if it does show a significant difference it correlates with the number of total created circuits. The more circuits are built, the higher the used CPU time. Even when enabling CPU delays and encryption in *Shadow* we were not able to observe any significant difference. Due to the unreliable nature of measuring the CPU time, using the total number of created circuits as a measure is preferred. Still, only very small MCDs like 30 s show an increased CPU usage. Therefore, halving the default MCD does not result in a degradation of performance.
**Memory Usage.** In Fig. 3, the total memory consumption in GiB of all guards and clients can be seen on the Y-axis. It is clearly visible that decreasing the MCD leads to an overall lower memory consumption while increasing the MCD shows the opposite effect and all guards have an increased memory usage. We see the same trend for the exit and middle relays. Halving the MCD leads to a decrease of about 22%, while doubling the MCD leads to an increase of about 59%. If we compare the amount of memory used in Fig. 3a and the number of concurrently active circuits in Fig. 1, we can see that those graphs are almost identical and there seems to be a correlation between those two metrics.

The same effect is also present for the client as seen in Fig. 3b albeit considerable lower. By reducing the MCD we can only see a very small difference of roughly 3%. By raising the MCD however, a noticeable difference can be seen up to an increase of about 23% for a MCD of 60 min.

<figure><img src="image_5.png" /><figcaption>**Fig. 3.** Memory used with a different MCD</figcaption></figure>

Scaling the simulation size to 8% of the Tor network yields the same results. Figure 4a shows the memory usage of all guards in the simulation with an unmodified and a halved default MCD. It can clearly be seen that the reduced MCD has a lower memory consumption of about 21%. The clients are affected as well but only show an increase in used memory by about 4%. Considering we simulate 63 355 clients the difference can be neglected. To verify these results we simulated a small network in *Chutney* with 10 clients and 18 relays, which shows the same trend. A reduced MCD leads to an overall decrease in memory usage. Since lowering the MCD leads to less concurrently active circuits, the amount of data that needs to be held in memory is also reduced and thus the results are as expected.

Since the memory is constantly rising for both the entire simulation and for each simulated entity, which is especially visible for the client, we investigated whether we could reproduce those findings. We used a small network with one authority node, one exit, one guard, one node with guard and exit capabilities
<figure><img src="image_6.png" /><figcaption>Fig. 4. Memory used with half the MCD</figcaption></figure>

and one middle node. 20 clients with access to 10 server were used in a simulation of 72 h. The memory consumption rises for all nodes in the network without showing a significant decrease. One might think we just missed the *free* calls or *Tor* might free memory in a different way. However, fluctuations can be seen during the whole operation. Additionally, the memory usage of the whole simulation rises constantly which is measured using a different method and independent of the memory allocation in the simulated application. Following the same trend as the graphs for the memory consumption of the clients (Fig. 3b, Fig. 4b), this simulation showed noticeable jumps in memory consumption throughout the entirety of the simulation. We were not able to reproduce these results using *Chutney* which hint towards the possibility of a memory leak in *Shadow*. This behavior can still be seen using *Shadow* version "2" and *Tor* version "0.4.6.8".

## 4.2 Privacy

To evaluate the risks of changing the MCD, we measure the Shannon entropy of Tor's circuit selection and simulate an adversary that is capable of end-to-end correlation attacks. Furthermore, we discuss the implications of a changed MCD with respect to other attacks on Tor. We note that small changes to the MCD do not compromise privacy, larger changes need to be investigated further.

First, we review the impact on circuit selection. To compute the Shannon entropy in our simulations, all combinations of selected input and output combinations were used as input. After about 10 min of simulated time, the entropy stabilizes and stays constant throughout the remaining simulation. For all evaluated values of the MCD and without changing the circuit selection mechanism, a maximum deviation of about 0.2% is observed and, thus, falls within the margin of error.

While simulating an adversary who controls 10% of Tor's guard and exit bandwidth with an unmodified entropy for circuit selection, we could not determine a significant difference in the total amount of compromised traffic for any
MCD. However, the number of compromised circuits scales with the total amount of created circuits. An MCD of 5 min results in 3% more circuits only while an MCD of 30 s results in 50% more circuits. The rate of compromise does not change.

<figure><img src="image_7.png" /><figcaption>**Fig. 5.** Megabytes transferred per circuit with different MCD settings</figcaption></figure>

Figure 5 shows the cumulative distribution fraction for transferred megabytes per circuit. Figure 5a shows that the lower the MCD, the less data is transferred per circuit. If we focus on the MCD of 5 min we see practically no difference to the default MCD (Fig. 5b). These results are in line with the total amount of created circuits, where we could only observe a significant difference for a low MCDs of 30 s. For higher MCDs, the data transferred per circuit is roughly the same.

Overall, changing the MCD does not affect the amount of compromised data. However, a reduction to 30 s results in 50% more circuits and the time to first compromise in end-to-end correlation attacks is reduced. The actual effects of more generated circuits on different attacks needs to be investigated in future work. The impact of halving the default MCD from 10 min to 5 min could be acceptable, as this results in only 3% more circuits.

## 4.3 Impact on Other Attacks

Results show that with lower MCDs, the number of created circuits increases. Each newly created circuit also increases the probability of selecting a compromised relay. This results in a higher risk of traffic correlation attacks [15]. An increase of circuits might reduce the time of first compromise. Whether and to what extent this is the case could be subject of further research.

The impact of different MCDs on attacks, such as circuit or website fingerprinting, depends on the aspects of the actual attack, underlying adversary model and user behavior. By decreasing the MCD, circuits are generally closed earlier.
Consequently, they are used for fewer connections which facilitates the distinction of different contexts for an adversary [32]. For users of the Tor Browser, this circumstance does not pose a significant additional threat as the browser isolates circuits to the URL bar domain [20]. The adversary would therefore gain little additional knowledge. However, there is no solution for Tor users that do not rely on the Tor browser yet. The specific effects of very short MCD, have yet to be studied.

# 5 Conclusion

After evaluating different MCDs, our results show that lowering the MCD from a default of 10 min to 5 min greatly reduces the memory usage of Tor relays. The initial concern that low MCDs might negatively impact the CPU usage or throughput proved to be mostly unfounded. Only for the original MCD of 30 s a degradation could be observed and leads to a significant increase of generated circuits. This did not, however, apply to any other tested MCDs. In fact, lowering the MCD to 5 min only results in a slight increase of circuits but reduces the memory consumption by 20%.

With a reduced MCD, alternative circuit selection strategies, that would usually be impractical due to high memory usage or large number of concurrently open circuits, could now become a feasible option. This includes, e.g., isolating streams based on their target, which was analyzed by Kiran et al. [17].

During the evaluation, we noticed a memory leak caused by either *Tor* or *Shadow*. We were not able to reproduce the issue neither outside the simulation nor to find the cause of that leak. Fixing the issue might allow for larger simulation setups or to even free additional memory of Tor relays.

While we simulated the Tor network during different time periods and used different seeds for the simulation, the underlying traffic model did not change. Our results are therefore dependent on the accuracy of this particular traffic model. Moreover, the model is based on a default MCD of 10 min which might impact the obtained results. Tests with other traffic models could help to clarify whether this might have introduced a bias or skewed the data otherwise.

Finally, the evaluation focused specifically on performance aspects of our simulation. Future work should also pay attention to the possible impact on security aspects, i.e., how changes to the MCD might influence traffic correlation and circuit or website fingerprinting attacks.

# References

1. AlSabah, M., Bauer, K., Elahi, T., Goldberg, I.: The path less travelled: overcoming tor's bottlenecks with traffic splitting. In: De Cristofaro, E., Wright, M. (eds.) PETS 2013. LNCS, vol. 7981, pp. 143–163. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-39077-7_8

2. Diaz, C.: Anonymity metrics revisited. In: Dagstuhl Seminar Proceedings. Schloss Dagstuhl-Leibniz-Zentrum für Informatik (2006)
3. Díaz, C., Seys, S., Claessens, J., Preneel, B.: Towards measuring anonymity. In: Dingledine, R., Syverson, P. (eds.) PET 2002. LNCS, vol. 2482, pp. 54–68. Springer, Heidelberg (2003). https://doi.org/10.1007/3-540-36467-6_5

4. Google Inc., Let's Make the Web Faster - Google Code, 26 May 2010. https://web.archive.org/web/20120324082535/https://code.google.com/speed/articles/web-metrics.html. Accessed 13 Jan 2022

5. Hanley, H., et al.: DPSelect: a differential privacy based guard relay selection algorithm for Tor. In: PoPETs 2019, no. 2 (2019)

6. Heaptrack. KDE Applications. https://apps.kde.org/heaptrack/. Accessed 13 Jan 2022

7. HTTP Archive: Page Weight (2021). https://archive.org/reports/page-weight. Accessed 06 Jan 2022

8. Imani, M., Amirabadi, M., Wright, M.: Modified relay selection and circuit selection for faster tor. IET Commun. 13(17), 2723–2734 (2019)

9. Jansen, R.: Shadow - the shadow simulator. https://shadow.github.io/. Accessed 13 Jan 2022

10. Jansen, R.: Shadow/Tornettools. shadow, 10 July 2021. https://github.com/shadow/tornettools. Accessed 13 Jan 2022

11. Jansen, R., Hopper, N.: Shadow: running tor in a box for accurate and efficient experimentation (2012)

12. Jansen, R., Johnson, A.: Safely measuring tor. In: CCS, pp. 1553–1567. ACM (2016)

13. Jansen, R., Tracey, J., Goldberg, I.: Once is never enough: foundations for sound statistical inference in tor network experimentation. arXiv preprint arXiv:2102.05196 (2021)

14. Jansen, R., Traudt, M., Hopper, N.: Privacy-preserving dynamic learning of tor network traffic. In: CCS, pp. 1944–1961. ACM (2018). https://doi.org/10.1145/3243734.3243815

15. Johnson, A., et al.: Users get routed: traffic correlation on tor by realistic adversaries. In: CCS, pp. 337–348. ACM (2013)

16. Kim, H., Lee, S., Kim, J.: Inferring browser activity and status through remote monitoring of storage usage. In: ACSAC, pp. 410–421. ACM (2016). https://doi.org/10.1145/2991079.2991080

17. Kiran, K., et al.: Anonymity and performance analysis of stream isolation in tor network. In: ICCCNT, pp. 1–6. IEEE (2019)

18. Koch, R., Golling, M., Rodosek, G.D.: Disequilibrium: tor's exit node selection under the stereoscope. In: Trustcom/BigDataSE/ISPA, vol. 1, pp. 942–949. IEEE (2015)

19. Mani, A., et al.: Understanding tor usage with privacy-preserving measurement. In: IMC, pp. 175–187 (2018)

20. Perry, M., et al.: The design and implementation of the tor browser [DRAFT]. 15 June 2018. https://2019.www.torproject.org/projects/torbrowser/design/. Accessed 13 Jan 2022

21. Resource.h « Linux « Uapi « Include - Kernel/Git/Torvalds/Linux.Git - Linux Kernel Source Tree. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/resource.h#n66. Accessed 13 Jan 2022

22. Jansen, R.: OnionTrace. shadow, 6 October 2020. https://github.com/shadow/oniontrace. Accessed 13 Jan 2022

23. Jansen, R.: TGen. shadow, 6 October 2020. https://github.com/shadow/tgen. Accessed 13 Jan 2022
24. Serjantov, A., Danezis, G.: Towards an information theoretic metric for anonymity. In: Dingledine, R., Syverson, P. (eds.) PET 2002. LNCS, vol. 2482, pp. 41–53. Springer, Heidelberg (2003). https://doi.org/10.1007/3-540-36467-6_4

25. Shannon, C.E.: A mathematical theory of communication. Bell Syst. Tech. J. **27**(3), 379–423 (1948)

26. Shen, S., Gao, J., Wu, A.: Weakness identification and flow analysis based on tor network. In: CNS, pp. 90–94. IEEE (2018)

27. Sun, Y., et al.: RAPTOR: routing attacks on privacy in tor. In: Usenix Security, pp. 271–286 (2015)

28. Syverson, P., Dingledine, R., Mathewson, N.: Tor: the second-generation onion router, pp. 303–320 (2004)

29. The Tor Project. Welcome to Tor Metrics. https://metrics.torproject.org/. Accessed 13 Jan 2022

30. Tor Project. Chutney - The Chutney Tool for Testing and Automating Tor Network Setup. https://gitweb.torproject.org/chutney.git. Accessed 13 Jan 2022

31. Wacek, C., et al.: An empirical evaluation of relay selection in tor. In: NDSS (2013)

32. Wang, T., Goldberg, I.: Improved website fingerprinting on tor. In: WPES, pp. 201–212. ACM (2013)